Celestin Apprentice 4/Apprentice-Release4.iso/Information/Digests/CSMP Digest/volume 3/csmp-digest-v3-057/doubleCR.1

Text File | 1995-12-31 | 287.8 KB | 7,223 lines

C.S.M.P. Digest             Tue, 13 Sep 94       Volume 3 : Issue 57

Today's Topics:

        Best Sprite Package?
        CW PASCAL vs THINK PASCAL
        Items in system menu bar
        Text searches.
        Ticks (was: Clover+. interrupt?)
        What is the point of MPW?
        Where have the standards gone? [a high level question]



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Gavin K Maxwell)
Subject: Best Sprite Package?
Date: 19 Aug 1994 06:15:19 GMT
Organization: Microplex Pty Ltd

I would like to know peoples impressions of the available sprite
animation libraries.  The two I'm aware of are SpriteWorld and Sprite
Animation Toolkit (SAT), are there any others?  Which is the best?
Are there any gotchas to watch out for?  What are their limitations?

Any help would be appreciated,
--
Gavin,
+---------------------+-----------------------------+      |||||||
| Gavin Maxwell,      | "You can't have everything. |      | _ _ |
| [e-mail] |  Where would you put it!!"  |      | O O |
| [phone]       |                             |      |  ^  |
+---------------------+-----------------------------+       \ ~ /
                                                             ---

+++++++++++++++++++++++++++

>From [e-mail] (Mike Balfour)
Date: 19 Aug 1994 14:47:14 GMT
Organization: Overload Engineering

In article <331iln$[e-mail]>, [e-mail] (Gavin K
Maxwell) wrote:

> I would like to know peoples impressions of the available sprite
> animation libraries.  The two I'm aware of are SpriteWorld and Sprite
> Animation Toolkit (SAT), are there any others?  Which is the best?
> Are there any gotchas to watch out for?  What are their limitations?
>

Well, it seems that more people out there are using SpriteWorld, just
because it was released about a month before SAT.  SpriteWorld is also more
geared to C, where SAT was originally written for Pascal and has since been
updated to be usable from C.  Between the two, I'm very biased toward SAT.
I beta-tested it for several months, and I found it was very easy to learn,
easy to use, and just good quick code.  It even makes my bad code run fast
(who else can claim that?)!  Somebody else recently posted the concern that
SAT still has warnings in it from the author, Ingemar, about various
kluges.  I wouldn't be concerned - everything's actually amazingly stable.
I should know, I tried some pretty strange things from time to time to try
to make it break...

MB
--
- --------------------------------+--------------------------------
Mike Balfour, Partner             | BS/MS Candidate - ECMP
Overload Engineering              | Case Western Reserve University
"New Ideas for a Brighter Future" | Cleveland, OH

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 19 Aug 94 14:57:16 GMT
Organization: PowerTools, Austin, Texas

In article <331iln$[e-mail]> [e-mail] (Gavin K Maxwell) writes:

>I would like to know peoples impressions of the available sprite
>animation libraries.  The two I'm aware of are SpriteWorld and Sprite
>Animation Toolkit (SAT), are there any others?  Which is the best?
>Are there any gotchas to watch out for?  What are their limitations?

You might want to have a look at Graphic Elements. To my way of thinking,
it offers a lot more flexibility than either SpriteWorld or SAT -- but
then, I'm the author:-)

As to which is best for you, that probably depends on what you want
to do. Graphic Elements has lots of built-in features: buttons and
sliders, horizontal and vertical mirroring, special effects. SpriteWorld
has good performance with free licensing and complete source code. SAT
has both C and Pascal interfaces and offers excellent support for older
systems. Both Graphic Elements and SpriteWorld offer native PPC support;
I'm not sure about SAT.
                    --Al Evans--
--
Al Evans        |   Graphic Elements: A new standard for
________________________|__ high-performance interactive Macintosh graphics.
[e-mail] |  Available from mac.archive.umich.edu
- -------------------------| /mac/development/libraries/graphicelements2.sit.hqx

+++++++++++++++++++++++++++

>From [e-mail] (Will Iverson)
Date: Fri, 19 Aug 1994 18:01:34 GMT
Organization: University of California, Davis

In article <[e-mail]>, [e-mail] (Al
Evans) wrote:

> In article <331iln$[e-mail]> [e-mail] (Gavin K
Maxwell) writes:
>
> As to which is best for you, that probably depends on what you want
> to do. Graphic Elements has lots of built-in features: buttons and
> sliders, horizontal and vertical mirroring, special effects. SpriteWorld
> has good performance with free licensing and complete source code. SAT
> has both C and Pascal interfaces and offers excellent support for older
> systems. Both Graphic Elements and SpriteWorld offer native PPC support;
> I'm not sure about SAT.

SAT (as of version 2.1.2) doesn't offer native PPC support.

-Will Iverson

+++++++++++++++++++++++++++

>From [e-mail] (DICTUS ROY)
Date: 20 Aug 1994 21:50:45 GMT
Organization: Brussels Free Universities (VUB/ULB), Belgium

I've looked at all three packages a while ago; SAT, SpriteWorld and
Graphics Elements.

I've written a few games using SAT and was most impressed with it.  Good
interface, logical structure, fast and reliable code.

SpriteWorld looks good too, but seems much harder to use than SAT.

Graphics Elements, to be frank, I wasn't very impressed with (no offense
to the author).  I liked SAT and SW better.

I'll stick to SAT.  I just like it the best and it has proven itself.

Games on the Net that were written with SAT:
- Asterax
- Bachman 2
- CyberNation
- Missions of the Reliant
- Warbirds
- ...

How many games have been written with SpriteWorld?  I don't recall ever
having seen any reference to it in any game...

Just my $0.02,

- Roy

+++++++++++++++++++++++++++

>From [e-mail] ( Dan Hampton )
Date: 25 Aug 1994 12:00:10 +1000
Organization: University of Wollongong, NSW, Australia.

[e-mail] (DICTUS ROY) writes:

>I've looked at all three packages a while ago; SAT, SpriteWorld and
>Graphics Elements.

>I've written a few games using SAT and was most impressed with it.  Good
>interface, logical structure, fast and reliable code.

>SpriteWorld looks good too, but seems much harder to use than SAT.

>Graphics Elements, to be frank, I wasn't very impressed with (no offense
>to the author).  I liked SAT and SW better.

>I'll stick to SAT.  I just like it the best and it has pr
>Games on the Net that were written with SAT:
>- Asterax
>- Bachman 2
>- CyberNation
>- Missions of the Reliant
>- Warbirds
>- ...

>How many games have been written with SpriteWorld?  I don't recall ever
>having seen any reference to it in any game...

Yeah that is true, It'd be interesting to see if anything decent has been
made with SpriteWorld. The latest version is very complete
and packed with features, PPC native, and extremely fast.

There can be a bit of fiddling around with things that you'd
rather not have to deal with thou.

Where can Graphic Elements be gotten from anyway? (ftp site {which one})


- --------------------------------------------------------------------
It is an important and popular fact that things are not always what
they seem.  For instance, on the planet Earth, man had always assumed
that he was more intelligent than dolphins because he had achieved so
much -- the wheel, New York, wars and so on -- whilst all the dolphins
had ever done was muck about in the water having a good time.  But
conversely, the dolphins had always believed that they were far more
intelligent than man -- for precisely the same reasons.
             -- Douglas Adams "The Hitch-Hikers' Guide To The Galaxy".
- --------------------------------------------------------------------
Dan Hampton -- Austinmer, NSW, Australia.          <[e-mail]>
- --------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 25 Aug 94 14:29:13 GMT
Organization: PowerTools, Austin, Texas

In article <33gtva$[e-mail]> [e-mail] ( Dan Hampton ) writes:

>Yeah that is true, It'd be interesting to see if anything decent has been
>made with SpriteWorld. The latest version is very complete
>and packed with features, PPC native, and extremely fast.

I have recently done some (contract) finishing work on a piece of
educational software from a major educational publishing company that
used SpriteWorld for its animation.

>There can be a bit of fiddling around with things that you'd
>rather not have to deal with thou.

Although I did not deal directly with the animation routines in this
package, it seemed to me that they required an enormous number of
lines of code for what they did.

>Where can Graphic Elements be gotten from anyway? (ftp site {which one})

See my .signature.
                    --Al Evans--
--
Al Evans        |   Graphic Elements: A new standard for
________________________|__ high-performance interactive Macintosh graphics.
[e-mail] |  Available from mac.archive.umich.edu
- -------------------------| /mac/development/libraries/graphicelements2.sit.hqx

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 28 Aug 1994 10:28:19 GMT
Organization: (none)

[e-mail] (Will Iverson) writes:

>SAT (as of version 2.1.2) doesn't offer native PPC support.

This is true, and the reason is that CodeWarrior is so damn buggy! I've tried
porting some smaller hacks to it, and I'm getting tired of rebooting over
and over again, with the debugger not catching any problems at all.

Actually, if there is some SKILLED programmer out there, with some
experience with CodeWarrior Pascal, I'd be happy to let him/her try porting
it. Perhaps a CodeWarrior version could skip the 68000 support and all
blitters except 8-bit, just to get it running for PPC?

Considering what package is BEST, I think it's a matter of needs and taste.

SW is written as an Apple Manager. Fairly general, not too quick to get
started with, handles sprite management only. I found it a little worrying
to find out that it's made by a programmer who hasn't made a computer game
in his life (that we know of). I mean, if HE can't make games with it,
why should I believe I can? (The big problem I'm aiming at is the lack of
a full game demo.) I'm not sure it has more USERS than SAT. More
people have it, and I'm sure lots of people grab code from it, but who
knows how many people uses it? It has some strong points, like staggered
drawing (which isn't impossible in SAT, but a bit harder) and grouping
the sprites in distinct so-called layers.

SAT is written for kick-start coding, for getting up in the air quickly,
with a very small set of calls for the beginner. It includes asynch sound,
simply because 99.9% of the programmers will need that too, and you don't
want all the hassle making it work with Sound Manager 2! Good support for
Pascal as well as C is a must. Pascal is easier to work with, and SAT is
made to be beginner-friendly. NONE of the others support Pascal to any
extent that is worth mentioning. SAT clearly has the best support for
Macs not supporting 8-bit color (i.e. old Macs and Powerbooks), and supports
scrolling games.

Graphical Elements, I've hardly had time to look at that at all, but I got the
impression of a slightly different scope, not only at games. (I'll leave
it to Al to make more specific statements.)

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: 29 Aug 94 03:21:33 GMT
Organization: Apanix Public Access Unix, [phone] (5 lines)

[e-mail] (Mike Balfour) writes:

>In article <331iln$[e-mail]>, [e-mail] (Gavin K
>Maxwell) wrote:

>> I would like to know peoples impressions of the available sprite
>> animation libraries.  The two I'm aware of are SpriteWorld and Sprite
>> Animation Toolkit (SAT), are there any others?  Which is the best?
>> Are there any gotchas to watch out for?  What are their limitations?

>Well, it seems that more people out there are using SpriteWorld, just
>because it was released about a month before SAT.  SpriteWorld is also more
>geared to C, where SAT was originally written for Pascal and has since been
>updated to be usable from C.  Between the two, I'm very biased toward SAT.
>I beta-tested it for several months, and I found it was very easy to learn,
>easy to use, and just good quick code.  It even makes my bad code run fast
>(who else can claim that?)!  Somebody else recently posted the concern that
>SAT still has warnings in it from the author, Ingemar, about various
>kluges.  I wouldn't be concerned - everything's actually amazingly stable.
>I should know, I tried some pretty strange things from time to time to try
>to make it break...

I'm not sure about the "more people use SpriteWorld" claim, but
there have been several shareware games released lately that use
SAT. And there are several more on the way. Seems to be a fairly
hip and happening product.

--
David Wareing
Adelaide, South Australia         [e-mail]
- ------------------------------------------------------------
Freelance Macintosh Games & Multimedia Programming

---------------------------

>From [e-mail] (JOHN CHRISTIE)
Subject: CW PASCAL vs THINK PASCAL
Date: 18 Aug 94 11:57:04 -0300
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

PASCAL keeners read this

    Has anyone here used MW PASCAL and THINK PASCAL.  I would be terribly
interested in hearing how they compare from those who have used them.

                        Thanks
                        John

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Fri, 19 Aug 1994 11:07:15 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <1994Aug18.115704.26744@dal1>, [e-mail] (JOHN CHRISTIE) wrote:

>        Has anyone here used MW PASCAL and THINK PASCAL.  I would be terribly
>interested in hearing how they compare from those who have used them.

The big difference between MW Pascal and Think Pascal is that MW Pascal is
going somewhere, and Think Pascal isn't.  MW Pascal still has it's
problems (I'm still on 3.5 so my info may be out of date) but it's
certainly a usable tool.  [For 68K, the PPC one is very much a development
version.]  Think Pascal is, quite simply, the nicest development
environment for the Macintosh.  *However* MW is catching up quick and
Think isn't going anywhere ):  [for a variety of technical and marketting
reasons]  So it'll only be a matter of time before MW wins.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Daniel W. Rickey)
Date: 18 Aug 1994 19:06:11 GMT
Organization: Imaging Research Labs


I have tried both.  Actually, I have not had a chance try out the
latest release (CW4).  Version 3.5 was still too buggy to evaluate
properly.  However, it looks like debugging in Think Pascal is much
easier.  CW has a different way of implementing writelns - it
automatically creates an output window like TP, and it takes over the
menu bar.  This makes the writeln mechanism mostly useless for
debugging (as far as I can tell).  It will probably be a long time
before the CW debugger is as nice as the ThinkP debugger...but we can
hope!

Moving code from ThinkP to CW is proving to be "interesting".  A few
library functions are missing in CW, although this is not too big of a
deal.  There may be a few other differences in the way typecasting/type
conversions are done between the two compilers.

One of the VERY nice features of CW is that it gives compile time
warnings, e.g., variable declared but not used, etc.  The CW pascal and
C compilers are also very similar, unlike Symantec's compilers.  This
should make mixing of C and Pascal code in the same application much
easier.


Daniel W. Rickey
drickey@.irus.rri.uwo.ca

Imaging Research Laboratories
The J.P. Robarts Research Institute
100 Perth Drive
London, Ontario
CANADA  N6A 5K8

+++++++++++++++++++++++++++

>From [e-mail] (Will Iverson)
Date: Thu, 18 Aug 1994 20:25:20 GMT
Organization: University of California, Davis

In article <1994Aug18.115704.26744@dal1>, [e-mail] (JOHN CHRISTIE) wrote:

> PASCAL keeners read this
>
>         Has anyone here used MW PASCAL and THINK PASCAL.  I would be terribly
> interested in hearing how they compare from those who have used them.
>
>                                                 Thanks
>                                                 John

I've used both, although I've used Think Pascal far more.  I haven't been
able to port my Think Pascal project over to MW Pascal yet because of
(apparent) lack of full SANE support (and maybe something else I haven't
found yet!) - although I'm not sure who to blame.

The Think debugger is fully integrated with the editor.  You want to set a
breakpoint?  Just click while you're in the editor.  Lightsbugs lets you
look at memory, data structures, etc.  You can stop your program and
change values, as well as write small pieces of code to be executed
instantly from within the program.  I find the entire programming cycle to
be very short.

The debugger for MW is a seperate program, which has advantages &
disadvantages.  The good news is that you can edit a program without
resetting it, but it's a lot more of a pain to to set breakpoints.

The Think Editor supports pretty-printing, which means you can basically
forget about formatting and have it do it all for you.

The MW Editor is sparser (keyword & comment coloring, no pretty-printing).
It is smarter about things like having the cursor run off the right edge,
however.

Think Pascal hasn't seen an update in years. MW Pascal is being updated as
we speak, but doesn't feel as complete.  When I can switch my project over
to MW Pascal, then my whole lab will switch over and we'll get a couple
more copies of MW.

Of course, which is better also depends on what you're trying to do.

-Will Iverson

+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 19 Aug 1994 12:17:47 +0200
Organization: Computer Science Department, University of Cape Town

Will Iverson ([e-mail]) wrote:
: The Think debugger is fully integrated with the editor.  You want to set a
: breakpoint?  Just click while you're in the editor.  Lightsbugs lets you
: look at memory, data structures, etc.  You can stop your program and
: change values, as well as write small pieces of code to be executed
: instantly from within the program.  I find the entire programming cycle to
: be very short.

The Think Pascal environment is wonderful. If only it had been developed
properly - in same ways it is still the best but you can't allow
something to languish for so long without losing your lead eventually.

Another thing no one has mentioned in MW's favour: you get a free
C and C++ compiler thrown in with it ;)
--
Philip Machanick                      [e-mail]
Computer Science Department, University of he Witwatesrand
2050 Wits, South Africa 27(11)716-3309 fax [phone]
(at University of Cape Town until November: 27(21)650-4058)

+++++++++++++++++++++++++++

>From [e-mail] (David Oberst)
Date: Fri, 19 Aug 1994 15:10:03 GMT
Organization: Government of the NWT, Canada

In article <3320sb$[e-mail]> [e-mail] (Philip Machanick) writes:
>Another thing no one has mentioned in MW's favour: you get a free
>C and C++ compiler thrown in with it ;)
>--
>Philip Machanick                      [e-mail]
>Computer Science Department, University of he Witwatesrand
>2050 Wits, South Africa 27(11)716-3309 fax [phone]
>(at University of Cape Town until November: 27(21)650-4058)

Of course, to the true Pascalite, this could be considered a drawback
instead of a positive <g>.

      David Oberst/GNWT Bureau of Statistics/Yellowknife, NWT, Canada
      [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Sat, 20 Aug 1994 17:55:22 +0800
Organization: NCRPDA, Curtin University

>version.]  Think Pascal is, quite simply, the nicest development
>environment for the Macintosh.  *However* MW is catching up quick and
>Think isn't going anywhere ):  [for a variety of technical and marketting
>reasons]  So it'll only be a matter of time before MW wins.

"a matter of time" likely being somewhere around about the end of the year
when Metrowerks have said they will have their pascal compiler both
supporting objects and compiling to PPC.
   Peter.
--
Peter N Lewis <[e-mail]> - Macintosh TCP fingerpainter

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 21 Aug 1994 14:52:23 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <330bf3$[e-mail]>, [e-mail] (Daniel
W. Rickey) wrote:

>Moving code from ThinkP to CW is proving to be "interesting".  A few
>library functions are missing in CW, although this is not too big of a
>deal.  There may be a few other differences in the way typecasting/type
>conversions are done between the two compilers.

MW Pascal implements MPW Pascal, not Think Pascal.  I've used both Think
and MPW Pascal a lot and I know whether the differences lie.  But there
are lots of gotchas out there for hard-core Think Pascal users.  Good
luck.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 21 Aug 1994 14:53:05 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <3320sb$[e-mail]>, [e-mail] (Philip
Machanick) wrote:

>Another thing no one has mentioned in MW's favour: you get a free
>C and C++ compiler thrown in with it ;)
       ^^^
I'm not sure whether I'd consider this an advantage (:
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Vik Rubenfeld)
Date: 21 Aug 1994 13:41:55 GMT
Organization: Los Angeles Macintosh Group BBS

Q> MW Pascal implements MPW Pascal, not Think Pascal. I've used both
Q> Think and MPW Pascal a lot and I know whether the differences lie.
Q> But there are lots of gotchas out there for hard-core Think Pascal
Q> users. Good luck.

Could you post a list describing some of the differences? Thanks in advance.

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Mon, 22 Aug 1994 10:55:49 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail] wrote:

>Could you post a list describing some of the differences? Thanks in advance.

This is covered in one of the appendices in the Think Pascal reference manual.

My personal favourite gotcha is the differences in the built-in string
function copy.  MPW (and MW) returns '' if any of the parameters are out
of bounds whereas Think makes a best effort.

eg copy('abcd', 3, 255) returns '' in MPW and MW and 'cd' in Think.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Michael Trent)
Date: 22 Aug 1994 23:08:50 GMT
Organization: Beloit College

Quinn "The Eskimo! ([e-mail]) wrote:
: In article <1994Aug18.115704.26744@dal1>, [e-mail] (JOHN CHRISTIE) wrote:

: >        Has anyone here used MW PASCAL and THINK PASCAL.  I would be terribly
: >interested in hearing how they compare from those who have used them.

: The big difference between MW Pascal and Think Pascal is that MW Pascal is
: going somewhere, and Think Pascal isn't.

AMEN BROTHER!

As cool as it is to have a "We will not be Emulated!" c/c++ compiler, it was
a new Pascal that drove me to order MWCW Gold!  I've spent too much time
fighting the age of THINK Pascal to enjoy it anymore.

--
      Mike Trent        |  Macintosh Specialist  |   Beloit College
[e-mail]  |   Academic Computing   |  Beloit Wisconsin

+++++++++++++++++++++++++++

>From [e-mail] (Keng Ng)
Date: 23 Aug 1994 11:46:16 GMT
Organization: Imperial College, Dept. of Computing

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

> >version.]  Think Pascal is, quite simply, the nicest development
> >environment for the Macintosh.  *However* MW is catching up quick and
> >Think isn't going anywhere ):  [for a variety of technical and marketting
> >reasons]  So it'll only be a matter of time before MW wins.
>
> "a matter of time" likely being somewhere around about the end of the year
> when Metrowerks have said they will have their pascal compiler both
> supporting objects and compiling to PPC.
             ^^^^^^^

Does that mean that we'll be able to use it for MacApp 2.0.1 projects ?

-Keng
_________________________________________________________________

 Keng T. Ng                      Email:   [e-mail]
 Imperial College,
 Dept. of Computing,             Phone:   [phone]
 180 Queen's Gate,               Fax:     [phone]
 London SW7 2BZ, UK
_________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 25 Aug 1994 11:30:54 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <kn-2308941245290001@146.169.14.31>, [e-mail] (Keng Ng) wrote:

>Does that mean that we'll be able to use it for MacApp 2.0.1 projects ?

For PPC code?  Unlikely without a lot of work.  MacApp 2.0.1 is full of
lots of skanky things that make taking it native tricky.  Specifically:
exception handling.
--
Quinn "The Eskimo!"        "Scout in a can. Simple, cheap, easy
                            to use and it's expendable!"

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 25 Aug 1994 12:38:05 +0800
Organization: NCRPDA, Curtin University

In article <[e-mail]>,
[e-mail] (Quinn "The Eskimo!") wrote:

>My personal favourite gotcha is the differences in the built-in string
>function copy.  MPW (and MW) returns '' if any of the parameters are out
>of bounds whereas Think makes a best effort.
>
>eg copy('abcd', 3, 255) returns '' in MPW and MW and 'cd' in Think.

Yeah, this is mind nummingly anoying (although not quite annoying as DR/2s
behaviour of copy :-)

 function TPcopy (source: string; start, count: integer): string;
  var
   i: integer;
 begin
  if (start < 1) then begin
   count := count - (1 - start);
   start := 1;
  end;
  if start + count > length(source) then begin
   count := length(source) - start + 1;
  end;
  if count < 0 then begin
   count := 0;
  end;
  source[0] := chr(count);
  BlockMove(@source[start], @source[1], count);
  TPcopy := source;
 end;

Non optiomal, but who cares?

Enjoy,
   Peter.
--
Peter N Lewis <[e-mail]> - Macintosh TCP fingerpainter

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 28 Aug 1994 09:54:00 GMT
Organization: (none)

[e-mail] (Peter N Lewis) writes:

>>version.]  Think Pascal is, quite simply, the nicest development
>>environment for the Macintosh.  *However* MW is catching up quick and
>>Think isn't going anywhere ):  [for a variety of technical and marketting
>>reasons]  So it'll only be a matter of time before MW wins.

>"a matter of time" likely being somewhere around about the end of the year
>when Metrowerks have said they will have their pascal compiler both
>supporting objects and compiling to PPC.

I doubt it. Even though PPC support is a strong point, they are so much
behind in all other areas. No auto-indentation, not even on command. The
debugger is a pain in the ass compared to Lightsbug - and where are
Observe and Instant, my two favourite features? The debugger doesn't even
seem to catch any errors to speak of. I hate when the program stops running,
and the debugger says nothing, and I don't even know where it stopped.
And the resource file is handled in the BRAIN-DAMAGED way that Think C used
up to version 5.

I hope they can make a decent product of it, but I can see my productivity
going down... Back to the Lightspeed C days, when debugging took several
times longer, since there were no decent debugger arund.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 28 Aug 1994 10:00:26 GMT
Organization: (none)

[e-mail] (Vik Rubenfeld) writes:

>Q> MW Pascal implements MPW Pascal, not Think Pascal. I've used both
>Q> Think and MPW Pascal a lot and I know whether the differences lie.
>Q> But there are lots of gotchas out there for hard-core Think Pascal
>Q> users. Good luck.

>Could you post a list describing some of the differences? Thanks in advance.

Some obvious differences are that no managers are automatically used (thus,
I'm building up a set of stuff to "uses" in all files - finding out exactly
what standard managers to use is a pain), and initializations aren't
automatic. All QuickDraw globals are in a "qd" record.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jack W. Howarth)
Date: 28 Aug 1994 18:28:52 GMT
Organization: University of Texas Medical School

In article <33pn7q$[e-mail]>
[e-mail] (Ingemar Ragnemalm) writes:

> Some obvious differences are that no managers are automatically used (thus,
> I'm building up a set of stuff to "uses" in all files - finding out exactly
> what standard managers to use is a pain), and initializations aren't
> automatic. All QuickDraw globals are in a "qd" record.

Are you sure that some of your complaints are directed at the new
Universal Headers from Apple and not MW Pascal itself?

Jack W. Howarth, Ph.D.                Univ. of Texas Medical School
Research Fellow                                      P.O. Box 20708
Department of Biochemistry                     Houston, Texas 77225

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Mon, 29 Aug 1994 10:10:52 +0800
Organization: NCRPDA, Curtin University

>Some obvious differences are that no managers are automatically used (thus,
>I'm building up a set of stuff to "uses" in all files - finding out exactly
>what standard managers to use is a pain), and initializations aren't

ObiWan will tell you which unit to include for a given procedure.  I have
the same problem, but a few compiles and it's fixed.  Also, you can use
stuff like this:

{$IFC undefined THINK_Pascal}
   uses
      Events;
{$ENDC}

To avoid having to include all the dummy unix in THINK Pascal.
   Peter.
--
Peter N Lewis <[e-mail]> - Macintosh TCP fingerpainter

---------------------------

>From [e-mail] (Chris Magnuson)
Subject: Items in system menu bar
Date: 17 Aug 1994 20:17:44 GMT
Organization: HP Colorado Springs Division

  I was reading about the Menu Manager last night, trying to figure out
  how to stick icons in the Finder's menu bar (right up there next to
  the balloon, for example).  Anyone have any ideas on how to do this?
  Is this considered Menu #0 and you just GetMenuHandle() on that?

  Hmm.  Any hints would be appreciated.

  Thanks,
  Chris Magnuson
  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Spencer Low)
Date: Wed, 17 Aug 1994 15:33:08 -0800
Organization: LowTek Creations

In article <32tr98$[e-mail]>, [e-mail] (Chris
Magnuson) wrote:
>   I was reading about the Menu Manager last night, trying to figure out
>   how to stick icons in the Finder's menu bar (right up there next to
>   the balloon, for example).  Anyone have any ideas on how to do this?
>   Is this considered Menu #0 and you just GetMenuHandle() on that?

If you want to install a System Menu (i.e. ColorSwitch, OtherMenu, Help
menu, Application menu, etc.), check out the "star-menu" source at UMICH.
Or read up on TSM menus in Inside Mac: Text.

Spencer

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 25 Aug 1994 00:27:15 GMT
Organization: Apple Computer

Chris Magnuson, [e-mail] writes:
>   I was reading about the Menu Manager last night, trying to figure out
>   how to stick icons in the Finder's menu bar (right up there next to
>   the balloon, for example).  Anyone have any ideas on how to do this?
>   Is this considered Menu #0 and you just GetMenuHandle() on that?

There are really two things you want:
(1) How to give a menu an icon as a title. Simple: It has to have a five
character name, of which the first byte is '\01' (Ascii 01) and the other
four are a handle to an icon suite. Needless to say, don't dispose the icon
suite before the menu goes away.
(2) How to put a menu on the right side of the menu bar. There's a particular
range of negative menu IDs that signal a system menu; if you add a menu with
such an ID it automatically goes on the right side, and it automatically will
be added to the menu bar of every app that's launched. This means it's best
to install such menus as soon as the menu bar first comes up; e.g. by
patching DrawMenuBar. Make sure you load the icon into the System heap, of
course, otherwise it'll be disposed when the current app quits.

I believe there is sample code somplace showing how to do this.
Disclaimer: None of this stuff is supported by Apple (though it's cool) and
these techniques may break in the future.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Sun, 28 Aug 1994 18:39:36 -0800
Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?

In article <32tr98$[e-mail]>, [e-mail] (Chris
Magnuson) wrote:

>  I was reading about the Menu Manager last night, trying to figure out
>  how to stick icons in the Finder's menu bar (right up there next to
>  the balloon, for example).  Anyone have any ideas on how to do this?
>  Is this considered Menu #0 and you just GetMenuHandle() on that?


The following tips concerning being compatible with future Mac OSes were
distributed (I think) at the last WWDC:


7.  Extensions that try to modify menus in applications without their
knowledge will no longer work.

8.  Extensions that install menus in the system portion of the menu bar
will break if they access Menu Manager data without using the Menu Manager
API.

9.  Extensions that augment or override the behavior of the Apple menu
(like adding hierarchical menus) will break.


That said, here's an INIT written by someone in Mac DTS that does what
you're asking. Given the above warnings, I would consider the following
hack to be unsupported, but about as best as you can do given today's
Toolbox API.



;   Sample INIT that puts up a system wide menu and installs a handler for it.
;   The general idea of this is that it waits for the system to install a
system menu and then
;   when that menu is installed it installs its own menu. The patch to
SystemMenu is what is
;   used to determine what to do when an item is selected.
;
;   Use the following MPW commands to build the INIT:
;
;   asm SampleINIT.a -o SampleINIT.a.o
;   Link -o SampleINIT -rt INIT=128 -ra Main=resSysHeap -t INIT SampleINIT.a.o
;   duplicate SampleINIT "{SystemFolder}Extensions:aSampleINIT"
;
;   Hack courtesy of Apple Developer Tech Support
;   Change History:
;   12/10/93    JLM     Created the INIT and made items beep with sysbeep
;

            PRINT   PUSH,OFF            ; don't print any of this stuff

            INCLUDE 'ToolEqu.a'
            INCLUDE 'Traps.a'
            INCLUDE 'PackMacs.a'
            INCLUDE 'QuickEqu.a'
            INCLUDE 'SysEqu.a'

            PRINT   POP             ; restore the PRINT options

theStub         proc    Export
                Import  ENTRY
                bra     ENTRY
                EndP

MyGlobals       Record  0
OldInsertMenu   ds.L    1
OldSystemMenu   ds.L    1
MyMenuHand      ds.L    1
MyMenuID        ds.W    1
                EndR

tenderID        equ     $BF99       ; this looks like a good start
Globals         proc    Export
                ds      MyGlobals
                Export  MyMenuStr
MyMenuStr       dc      'Item1;Item2'       ;
                Export  MyMenuTitle
MyMenuTitle     dc      'SMU'               ; and our menu
                EndP

MyInsertMenu    proc    Export
InsMenuFrame    Record  {xA6Link},DECR
xParmBegin      equ     *
theMenu         ds.L    1
before          ds.W    1
xParmSize       equ     xParmBegin-*
xRetAddr        ds.L    1
xJumpThru       ds.L    1                   ; store the real address here
on stack for unwinding
xA6Link         ds.L    1
* Insert local vars here
ZoneSave        ds.L    1
xLocalSize      equ     *
                endr
                with    InsMenuFrame,MyGlobals
                clr.L   -(sp)               ; for the return address of
this routine
                LINK    A6,#xLocalSize
                movem.L D0-D2/A0-A4,-(sp)   ; save these temp registers
                lea     Globals,A4          ; get our globals pointer so
we can test further
                move.L  theMenu(A6),A0          ; get the menu handle
being installed
                move.L  (A0),A0             ; deref it
                tst.W   (A0)                ; see if its a system menu
                bpl.s   @IgnorePatch        ; if so ignore the patch stuff
                move.W  MyMenuID(A4),D0
                tst.W   D0                  ; see if we are installed yet...
                beq.s   @InstallMe          ; nope better install
ourselves first
                cmp.W   (A0),D0             ; see if our menu has the same
ID as this menu
                bne.s   @IgnorePatch        ; it does not, we can leave now

@IDConflict
; if we get here the system menu ID number we have choosen is in conflict
with a system menu
; used by the system. We could try to change our number or bail out. I
choose bailing out
; for this example. The proper thing to do might be to examine the menu
list and try a different
; number.
                move.W  MyMenuID(A4),-(sp)  ; first delete the menu from
the menu bar
                _DeleteMenu                 ; ok now the menu is deleted
                move.W  #1,MyMenuID(A4)     ; and reset our menu ID to not
ever be a system menu but be non-zero
                move.L  MyMenuHand(A4),-(sp)
                _DisposeMenu                ; and dump the menu itself
                move.L  #1,MyMenuHand(A4)   ; and zots the menu handle as well
                bra.s   @ignorePatch        ; and exit
@InstallMe
                move.L  theZone,zoneSave(A6)
                move.L  SysZone,A0
                _SetZone                    ; insure that the new menu
goes into the system heap

                clr.L   -(sp)               ; first create our menu
                move.W  #tenderID,-(sp)     ; move our projected ID on the stack
                pea     MyMenuTitle ; and push our title pointer
                _NewMenu
                move.L  (sp),MyMenuHand(A4) ; set up our menu handle in memory
                pea     MyMenuStr
                _AppendMenu                 ; now we have built us a menu
                move.W  #tenderID,MyMenuID(A4)

                move.L  zoneSave(A6),A0
                _SetZone                    ; switch back to the app heap

                move.L  MyMenuHand(A4),-(sp)
                move.W  #tenderID,-(sp)
                move.L  OldInsertMenu(A4),A0
                jsr     (A0)                ; call the real insert menu to
insert us
; ok, now we are inserted and we will work just fine...
;

@ignorePatch
; dummy up the stack to have the address of the real patch so's I can use
RTS to jump to
; the real patch instead of A0
                move.L  OldInsertMenu(A4),xJumpThru(A6)
                movem.L (sp)+,D0-D2/A0-A4   ; restore the stack
                unlk    A6                  ; and A6
                rts                         ; now call back the original
                EndP

MySystemMenu    proc    Export
InsMenuFrame    Record  {xA6Link},DECR
xParmBegin      equ     *
theItem         ds.W    1
theMenuID       ds.W    1
xParmSize       equ     xParmBegin-*
xRetAddr        ds.L    1
xJumpThru       ds.L    1                   ; store the real address here
on stack for unwinding
xA6Link         ds.L    1
* Insert local vars here
xLocalSize      equ     *
                EndR
                with    InsMenuFrame,MyGlobals
                clr.L   -(sp)               ; for the return address of
this routine
                LINK    A6,#xLocalSize
                movem.L D0-D2/A0-A4,-(sp)   ; save these temp registers
                lea     Globals,A4          ; get our globals pointer so
we can test further
                move.W  theMenuID(A6),D0
                cmp.W   MyMenuID(A4),D0     ; see if its our menu
                bne.s   @ignorePatch        ; if not simply call thru to
he other side
; else this is our menu, for right now we will simply beep at the user
                move.L  #$00050005,-(sp)    ; set up to beep twice
                _Sysbeep
                _SysBeep
; and since we handled the menu we will now return to the caller
                movem.L (sp)+,D0-D2/A0-A4   ; restore the stack
                unlk    A6                  ; and A6
                addQ.L  #4,sp               ; remove the long we pushed on
the stack earlier
                move.L  (sp)+,(sp)          ; and remove the return
address and place it on top of the parms
                rts                         ; and return to our regularly
scheduled app.

@ignorePatch
; dummy up the stack to have the address of the real patch so's I can use
RTS to jump to
; the real patch instead of A0
                move.L  OldSystemMenu(A4),xJumpThru(A6)
                movem.L (sp)+,D0-D2/A0-A4   ; restore the stack
                unlk    A6                  ; and A6
                rts                         ; now call back the original
                EndP

ENTRY           proc    export

                With    MyGlobals

                _Debugger                   ; enter the debugger so's I
can test this stuff out
                movem.L A0-A5/D0-D7,-(sp)   ; save regs to be safe
                lea     Globals,A4          ; set up our globals

                move.L  SysZone,A0
                _SetZone

                lea     theStub,A0          ; now get our handle detach
and lock it down its already
                _RecoverHandle              ; in the system heap
                move.L  A0,-(sp)
                _DetachResource             ; and detach the bad boy...

                Move.W  #$A935,D0           ; now insert my patch to
InsertMenu $A935
                _GetTrapAddress
                move.L  A0,OldInsertMenu(A4)

                lea     MyInsertMenu,A0
                Move.W  #$A935,D0
                _SetTrapAddress

                Move.W  #$A9B5,D0           ; now insert my patch to
SystemMenu $A9B5
                _GetTrapAddress
                move.L  A0,OldSystemMenu(A4)

                lea     MySystemMenu,A0
                Move.W  #$A9B5,D0
                _SetTrapAddress

                moveQ   #0,D0
                move.W  D0,MyMenuID(A4)
                Move.L  D0,MyMenuHand(A4)
                move.L  ApplZone,A0
                _SetZone

                movem.L (sp)+,A0-A5/D0-D7   ; save regs to be safe

                rts
                EndP


                End

- --------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton

---------------------------

>From [e-mail] (zorro)
Subject: Text searches.
Date: 16 Aug 1994 17:52:29 GMT
Organization: University of California; Santa Cruz



Constantly I find myself in the situation that Dina described... not knowing
where to look for a particulat #define, variable, or function.
So what I end up doing is uploading whole directories to my trusty Sparc
and using the 'grep' command. I realize this is wrong on a very basic level
and so what I want to ask is, does anyone know of an MPW Tool that duplicates
the functionality of 'grep'?
I could write one myself, all it would have to do is look through .c and .h
files for a text pattern, but I would prefer it if I didn't have to.

So, has anyone out there implemented 'grep'??

- Dan


+++++++++++++++++++++++++++

>From [e-mail] (Mike Crawford)
Date: Tue, 16 Aug 1994 19:08:16 GMT
Organization: The Cleveland Clinic Foundation

In article [e-mail], [e-mail] (zorro) writes:
>
>
>Constantly I find myself in the situation that Dina described... not knowing
>where to look for a particulat #define, variable, or function.
>So what I end up doing is uploading whole directories to my trusty Sparc
>and using the 'grep' command. I realize this is wrong on a very basic level
>and so what I want to ask is, does anyone know of an MPW Tool that duplicates
>the functionality of 'grep'?
>I could write one myself, all it would have to do is look through .c and .h
>files for a text pattern, but I would prefer it if I didn't have to.
>
>So, has anyone out there implemented 'grep'??
>
>- Dan
>


MPW† has a tool called 'search'  which functions just like the 'grep' command.

Ex.

search "Str255" {CIncludes}*.h   // searches all .h files in the current directory for
                // any occurance of 'Str255'

****† NOTE, the wildcard character is not an asterisk, it's a double skwiggly line and
can be created by the  option-x  key combination... I just couldn't duplicate it in
this message.  Sorry for the crudity of my example.

the search command is very useful... I use it daily

good luck

mwc

- ----------
Internet: [e-mail]
AOL:      [e-mail]
eWorld:   [e-mail]
- ----------
"And the people all said, "Sit down!" your rockin the boat..."
- ----------


+++++++++++++++++++++++++++

>From [e-mail] (Rich Siegel)
Date: Tue, 16 Aug 1994 23:01:36 GMT
Organization: Bare Bones Software

In article <32quct$[e-mail]> [e-mail] (zorro) writes:
>So what I end up doing is uploading whole directories to my trusty Sparc
>and using the 'grep' command. I realize this is wrong on a very basic level
>and so what I want to ask is, does anyone know of an MPW Tool that duplicates
>the functionality of 'grep'?
>
>So, has anyone out there implemented 'grep'??

Time to read the fine manual, particularly the chapter which describes
the "Search" tool. The MPW intrinsic "Help" has also proven safe and
effective when used as directed, particularly when combined with the
words "Expressions" and "Search".

R.
--
Rich Siegel % [e-mail]    % President & CEO, Bare Bones Software Inc.
--> For information about BBEdit, finger [e-mail] <--

+++++++++++++++++++++++++++

>From [e-mail] (Eric Bowman)
Date: 17 Aug 1994 03:56:27 GMT
Organization: Reed College,  Portland, Oregon

In article <32quct$[e-mail]>, zorro <[e-mail]> wrote:
>Constantly I find myself in the situation that Dina described... not knowing
>where to look for a particulat #define, variable, or function.
>So what I end up doing is uploading whole directories to my trusty Sparc
>and using the 'grep' command. I realize this is wrong on a very basic level
>and so what I want to ask is, does anyone know of an MPW Tool that duplicates
>the functionality of 'grep'?
>I could write one myself, all it would have to do is look through .c and .h
>files for a text pattern, but I would prefer it if I didn't have to.

Well, "Search" has all the functionality of "grep", except it uses MPW's
regular expression syntax instead of unix's.  Other than that, though, it
works great; better, even, than grep since it's so easy to jump to the
results of the search by double-clicking lines spewed out by search.

I just used it to do a very nasty search:  I needed to "touch" every
source file with an ASSERT, Debugger, or DebugStr (just got ETO 15!)...to
do this you need only do the following:

setfile -m . \d
`grep -s /[AD][Se][Sb][Eu][Rg][TSg][te]*[r]*\d(/ \x.cp | \d
streamedit -d -e '/File \d"(\x)\r1\d"\d;/ print \r1' | \d
sort -unique`

where
\d = option-d
\r = option-r
\x = option-x

Oh yeah, I have search aliased as "grep" :)

Just try and do *that* in any other IDE...

cheers,
bobo


+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 17 Aug 1994 15:26:30 +1200 (NZST)
Organization: (none)

[e-mail] (zorro) writes:
> Constantly I find myself in the situation that Dina described... not knowing
> where to look for a particulat #define, variable, or function.
> So what I end up doing is uploading whole directories to my trusty Sparc
> and using the 'grep' command. I realize this is wrong on a very basic level
> and so what I want to ask is, does anyone know of an MPW Tool that duplicates
> the functionality of 'grep'?
> I could write one myself, all it would have to do is look through .c and .h
> files for a text pattern, but I would prefer it if I didn't have to.

What's wrong with "search"?  Name too obscure, or something?

   search CloseWindow "{cincludes}"≈.h

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Wed, 17 Aug 1994 07:57:22 GMT
Organization: Adobe Systems Incorporated

 writes
> [e-mail] (zorro) writes:
> > Constantly I find myself in the situation that Dina described... not
knowing
> > where to look for a particulat #define, variable, or function.
> > So what I end up doing is uploading whole directories to my trusty Sparc
> > and using the 'grep' command. I realize this is wrong on a very basic
level
> > and so what I want to ask is, does anyone know of an MPW Tool that
duplicates
> > the functionality of 'grep'?
> > I could write one myself, all it would have to do is look through .c and
h
> > files for a text pattern, but I would prefer it if I didn't have to.
>
> What's wrong with "search"?  Name too obscure, or something?

There is a port of the GNU grep command to MPW. I picked it up off
ftp.apple.com a year or two ago. Its faster and has more functionality than
search. The Mac is still relatively slow at this sort of thing compared to a
decent UNIX box though.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
It seems like once people grow up, they have no idea what's cool. - Calvin

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Thu, 18 Aug 1994 03:11:36 +1200 (NZST)
Organization: (none)

[e-mail] (Zalman Stern) writes:
> There is a port of the GNU grep command to MPW. I picked it up off
> ftp.apple.com a year or two ago. Its faster and has more functionality than
> search. The Mac is still relatively slow at this sort of thing compared to a
> decent UNIX box though.

"search" used to be slow.  I wrote my own tool to search for literal strings
and it ran at 1.5 MB/sec on a Q700 with Quantum LPS240 HD, searching 40 MB of
200K files, while "search" ran at 300 KB/sec or so.

Then, a year or two ago, I got a new version of MPW and the search ran at the
same 1.5 MB/sec as my simple program did.  I've gone back to MPW Search ever
since.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Denizen of the Deep)
Date: 17 Aug 1994 16:35:59 GMT
Organization: Computer Science Department, Stanford University.

In article <32quct$[e-mail]>, zorro <[e-mail]> wrote:
>
>
>Constantly I find myself in the situation that Dina described... not knowing
>where to look for a particulat #define, variable, or function.
>So what I end up doing is uploading whole directories to my trusty Sparc
>and using the 'grep' command. I realize this is wrong on a very basic level
>and so what I want to ask is, does anyone know of an MPW Tool that duplicates
>the functionality of 'grep'?
>I could write one myself, all it would have to do is look through .c and .h
>files for a text pattern, but I would prefer it if I didn't have to.
>
>So, has anyone out there implemented 'grep'??
>
>- Dan
>


If you are working in MPW, there are tools you can use to accomplish the
same effect (though it's not as nice as grep IMHO).  The "files" tool
will list all the files in the specified directory, while the "search"
tool will search all the given files for the specified pattern.

In my worksheet, I have the following line marked as "Search in includes":

search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes`

This will search through all the MPW C header files for the given pattern.
In this case, it is searching for Gestalt.  To search for something else,
just change what's inside the '/' delimiters.  To search a different
directory, replace the "{mpw}"Interfaces:Cincludes with the directory
of your choice.  You can also specify the -r option to the files tool,
which will make the search recursively descend into subdirectories.

Hope that helps.

-Jon

+++++++++++++++++++++++++++

>From [e-mail] (Timothy Sherburne)
Date: 17 Aug 94 16:37:32 GMT
Organization: University of Portland

[e-mail] (Bruce Hoult) writes:

>[e-mail] (zorro) writes:
>> Constantly I find myself in the situation that Dina described... not knowing
>> where to look for a particulat #define, variable, or function.
>> So what I end up doing is uploading whole directories to my trusty Sparc
>> and using the 'grep' command. I realize this is wrong on a very basic level
>> and so what I want to ask is, does anyone know of an MPW Tool that duplicates
>> the functionality of 'grep'?
>> I could write one myself, all it would have to do is look through .c and .h
>> files for a text pattern, but I would prefer it if I didn't have to.

>What's wrong with "search"?  Name too obscure, or something?

>   search CloseWindow "{cincludes}"≈.h

>-- Bruce

All these suggestions to use the "search" tool are fine, but you can also install the "poptag" tool (found on the May '94 Tool Chest CD, but I couldn't find it on ETO 15 :(

It works like this:  highlight some function name, etc. and type cmd-P.  The definition will be given.

Works well IF you've got some extra space on your HD and the time to install it.

t
--
  | Timothy Sherburne                    |               Software Engineer |
  | Internet:  [e-mail]      |       Prometheus Products, Inc. |
  | AppleLink: [e-mail] |                  1-800-477-3473 |
*All comments are my own and in no way represent those of Prometheus Products*

+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Thu, 18 Aug 94 10:35:34 BST
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Zalman Stern) writes:

> There is a port of the GNU grep command to MPW. I picked it up off
> ftp.apple.com a year or two ago. Its faster and has more functionality than
> search. The Mac is still relatively slow at this sort of thing compared to a
> decent UNIX box though.

There's also "agrep" which is very fast; can't remember where I got
this from, but I can post to macgifts if people want it. Unfortunately,
it doesn't generate MPW-executable output like "Search", but it's dead
useful just for seeing which header file contains which definition.


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Larry Rosenstein)
Date: Fri, 19 Aug 1994 17:30:55 GMT
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] wrote:

> There's also "agrep" which is very fast; can't remember where I got
> this from, but I can post to macgifts if people want it. Unfortunately,

If it's the same one I'm thinking of, then this is a fast string searcher
that allows for errors in the text (ie, it's more of a fuzzy match).  The
information I have says the source is available at
ftp://cs.arizona.edu/agrep/.

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Tim Hammett)
Date: 20 Aug 1994 23:25:41 GMT
Organization: University of Auckland

[e-mail] (Denizen of the Deep) writes:
>search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes`

Why not use:

search -s /Gestalt/ "{CIncludes}=.h"

(where = is option-x, i.e. the squiggly equals sign)

--
Tim Hammett, School of Biological Sciences, Auckland University, New Zealand.
[e-mail]   Phone: [phone] x7298    FAX: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Wed, 24 Aug 1994 13:38:37 -0800
Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?

In article <32te9f$[e-mail]>, [e-mail]
(Denizen of the Deep) wrote:

>
>If you are working in MPW, there are tools you can use to accomplish the
>same effect (though it's not as nice as grep IMHO).


I have a question for you, Jon: What does "grep" do that makes it so much
nicer than "search"?


>The "files" tool
>will list all the files in the specified directory, while the "search"
>tool will search all the given files for the specified pattern.
>
>In my worksheet, I have the following line marked as "Search in includes":
>
>search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes`
>
>This will search through all the MPW C header files for the given pattern.
>In this case, it is searching for Gestalt.  To search for something else,
>just change what's inside the '/' delimiters.  To search a different
>directory, replace the "{mpw}"Interfaces:Cincludes with the directory
>of your choice.  You can also specify the -r option to the files tool,
>which will make the search recursively descend into subdirectories.


Geeze, you make it look so difficult. I simply use:

search Gestalt "{CIncludes}"<opt-x>

Actually, I fibbed. I never do that. I just select the item in my Edit
menu that lets me search a common directory. In my UserStarup*Keith file,
I have:

    Set FabFolders "`quote <opt-d>
                    '{CIncludes}' <opt-d>
                    '{PInterfaces}' <opt-d>
                    '{AIncludes}' <opt-d>
                    '{RIncludes}' <opt-d>
                    '{MACPlusIncludes}' <opt-d>
                    '{MALibraries}' <opt-d>
                    '{MPWCustom}Scripts:' <opt-d>
                    '{MPW}Scripts:' <opt-d>
                    `"

    For f in {FabFolders}
        AddMenu "Find" "Search in {f}" "SearchIn <opt-d>"{f}<opt-d>" <opt-d>
            <opt-w><opt-w> <opt-d>"<opt-d>{WorkSheet<opt-d>}<opt-d>""
    End


"SearchIn" is the following script:

    Set Expr "`Request 'Enter regular expression' || Echo ''`"
    Exit If "{Expr}" == ""
    open "{WorkSheet}"
    if "{expr}" =~ /[a-z0-9]+/
        Search "{Expr}" "{1}" <opt-x>
    else
        Search /{Expr}/ "{1}" <opt-x>
    end

- --------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton

+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Thu, 25 Aug 1994 16:06:09 -0800
Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?

In article <[e-mail]>,
[e-mail] wrote:

>In article <[e-mail]> (comp.sys.mac.programmer),
[e-mail] (Zalman Stern) writes:
>
>> There is a port of the GNU grep command to MPW. I picked it up off
>> ftp.apple.com a year or two ago. Its faster and has more functionality than
>> search. The Mac is still relatively slow at this sort of thing compared
to a
>> decent UNIX box though.
>
>There's also "agrep" which is very fast; can't remember where I got
>this from, but I can post to macgifts if people want it. Unfortunately,
>it doesn't generate MPW-executable output like "Search", but it's dead
>useful just for seeing which header file contains which definition.

I got a copy, dated Jan 1992, from cs.arizona.edu as agrep/agrep-2.04.tar.
Comes with source. I haven't tried it though.

- --------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton

+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Sun, 28 Aug 1994 18:21:13 -0800
Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows?

In article <3363dl$[e-mail]>, [e-mail]
(Tim Hammett) wrote:

>[e-mail] (Denizen of the Deep) writes:
>>search -s /Gestalt/ `files -o -f -t TEXT "{mpw}"Interfaces:CIncludes`
>
>Why not use:
>
>search -s /Gestalt/ "{CIncludes}=.h"
>
>(where = is option-x, i.e. the squiggly equals sign)


Using the following is much faster:

search -s Gestalt "{CIncludes}=.h"

The reason for this is that delimiting the search string with slashes
tells the Shell to perform a regular expression search. But the Shell can
also perform faster searches using a Boyer-Moore algorithm when it thinks
it's OK. Right now,  the only way it can tell this is when you feed it a
straight string. It would be nice if the searching routines would look in
the slashes and determine if it can use a Boyer-Moore search, but that's
not the way it works right now.

- --------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton

---------------------------

>From [e-mail] (Rich Martin)
Subject: Ticks (was: Clover+. interrupt?)
Date: Mon, 29 Aug 1994 14:58:16 -0500
Organization: Luddite Softwerks

PMJI, but this Ticks thing still haunts me. A project I worked on recently
was real-time intensive, and I assumed that Ticks would be incremented
every 1/60th second. IM told me that this was not guaranteed to happen
every time, but my assumption was that I would get no *more* than 60 ticks
in a second. All my time measurements went haywire. After much hair
pulling, we did some empirical tests and discovered that we were getting
something like 3605 ticks per minute. Yow! Slightly more than 60 ticks per
second! Over the course of 30 minutes, my program behaved as though it
were late when it actually was not. Once we accounted for this unexpected
Tick rate, timing improved sufficiently. Comments?
--
____________________________________________________________________
http://www.mps.ohio-state.edu/cgi-bin/hpp?RichMartin.html |   Not   |
__________________________________________________________| Insane! |
      It's Easy to be Easy when You're Easy...            |_________|

+++++++++++++++++++++++++++

>From [e-mail] (Michael Martz)
Date: 29 Aug 1994 20:41:40 GMT
Organization: Aldus Corporation, Seattle, WA USA

I had the very same thing happen to me a while ago. I set up code using
the time manager to count the number of ticks per second expecting to
find 55-60. When it turned out that I was getting 60+, I double checked
everything and then compared it to an external timing source. I
concluded that IM was incorrect.

I don't know why this occurs, but rest assured you are sane. For
periods around 30 minutes you really should be using the new Time
Manger rather than Ticks.

_______________________________________________________________________
Michael Martz           [e-mail]             Aldus Corp.

+++++++++++++++++++++++++++

>From [e-mail] (Mitchell S. Spector)
Date: 30 Aug 1994 09:24:58 -0700
Organization: Seattle University, Seattle, Washington, U.S.A.

In article <[e-mail]>,
Rich Martin <[e-mail]> wrote:
>PMJI, but this Ticks thing still haunts me. A project I worked on recently
>was real-time intensive, and I assumed that Ticks would be incremented
>every 1/60th second. IM told me that this was not guaranteed to happen
>every time, but my assumption was that I would get no *more* than 60 ticks
>in a second. All my time measurements went haywire. After much hair
>pulling, we did some empirical tests and discovered that we were getting
>something like 3605 ticks per minute. Yow! Slightly more than 60 ticks per
>second! Over the course of 30 minutes, my program behaved as though it
>were late when it actually was not. Once we accounted for this unexpected
>Tick rate, timing improved sufficiently. Comments?

   I know IM says in various places that a tick is 1/60 of a second.
But, according to the discussion of the video interface in IM vol. III,
the vertical scan rate of the original Macintosh monitor was 60.15 Hz,
not 60 Hz.  I presume this implies that VBL interrupts were generated
every 1/60.15 sec, a little faster than 1/60 sec.  This would mean that
there were 3609 ticks per minute.

   I have no idea if Apple has maintained compatibility with the
original Mac to the point of generating VBL interrupts at exactly
the same frequency as on the original Mac.  But I take all this to
mean that Apple does not guarantee the exact frequency of the VBL
interrupt, and that no program should use ticks for exact timing.
The Time Manager should be used for that.

>--
>____________________________________________________________________
>http://www.mps.ohio-state.edu/cgi-bin/hpp?RichMartin.html |   Not   |
>__________________________________________________________| Insane! |
>      It's Easy to be Easy when You're Easy...            |_________|

--
Mitchell Spector
Dept. of Computer Science and Software Engineering
Seattle University
E-mail: [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Tue, 30 Aug 1994 20:33:13 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Rich Martin) wrote:

>were late when it actually was not. Once we accounted for this unexpected
>Tick rate, timing improved sufficiently. Comments?

Yeah, there are 60.15 ticks per second. This is documented.

What you should do is use the
NewImprovedREALLYDriftFreeTimeManager to install a
ReallyDriftFree TimeManager task that increments a variable.
The plus side of this is that you get to set the interval of
the "ticks"

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 30 Aug 1994 18:16:06 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <33vmgq$[e-mail]>, [e-mail]
(Mitchell S. Spector) writes:

<<I have no idea if Apple has maintained compatibility with the
original Mac to the point of generating VBL interrupts at exactly
the same frequency as on the original Mac.>>

Apple has maintained compatibility; regardless of the actual monitor
frequency, a "VBL" interrupt is synthesized, supposedly at the original
60.15/sec rate. As others have mentioned using the Ticks/VBL mechanism for
accurate timing is not advised, because (a) the frequency is not
guaranteed, and (b) VBL tasks (and updating Ticks) don't happen while
interrupts are disabled.

Gregory Jorgensen
Radix Consulting Inc.

---------------------------

>From [e-mail] (tfullert)
Subject: What is the point of MPW?
Date: 13 Aug 1994 15:39:41 GMT
Organization: The Ohio State University

Hi:

I was given a copy of MPW 3.3 (not pirated, I was given all of the
materials in the huge box),and have the current shell from CodeWarrior.
 I am doing all of my own work on CodeWarrior and I want to devote some
energy to learning MPW.  What priority should I give this, though.
Exactly what can I do with MPW which I cannot do with CodeWarrior or
SC++?

Thanks;

Tim

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sat, 13 Aug 1994 20:06:23 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (tfullert) writes:
>I was given a copy of MPW 3.3 (not pirated, I was given all of the
>materials in the huge box),and have the current shell from CodeWarrior.
> I am doing all of my own work on CodeWarrior and I want to devote some
>energy to learning MPW.  What priority should I give this, though.
>Exactly what can I do with MPW which I cannot do with CodeWarrior or
>SC++?

       The MPW compilers are so out-of-date that unless you have old
software developed under MPW you need to maintain, don't bother.

       MPW is basically a UNIX-like command line oriented environment,
under which you can run various UNIX-like tools.  It's useful if you
need to build UNIX-like tools to process data as part of your
program-building process. MPW dates from when the Mac could only run
one program at a time, and it has its own hack for running "MPW tools"
under its own shell.

                        John Nagle

+++++++++++++++++++++++++++

>From mclow@san_marcos.csusm.edu (Marshall Clow)
Date: Sat, 13 Aug 1994 13:53:09 -0800
Organization: Aladdin Systems

In article <32ipft$[e-mail]>,
[e-mail] (tfullert) wrote:

> Hi:
>
> I was given a copy of MPW 3.3 (not pirated, I was given all of the
> materials in the huge box),and have the current shell from CodeWarrior.
>  I am doing all of my own work on CodeWarrior and I want to devote some
> energy to learning MPW.  What priority should I give this, though.
> Exactly what can I do with MPW which I cannot do with CodeWarrior or
> SC++?
>
   Try this in CodeWarrior (or Think, for that matter). Build an
application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in
tools, putting the 'CODE' resources and the xDEF resources in a file of
type 'APPL', while each of the tools goes in a seperate file. Don't forget
to put the build date (and time) into the 'vers' resource so that testers
can tell exactily what they have. After you have built the application,
compress the resources in the application.

Oh yes, do this by choosing a single menu option.

--
Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 13 Aug 1994 16:59:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (John Nagle)
writes:

>[e-mail] (tfullert) writes:
>>I was given a copy of MPW 3.3 (not pirated, I was given all of the
>>materials in the huge box),and have the current shell from CodeWarrior.
>> I am doing all of my own work on CodeWarrior and I want to devote some
>>energy to learning MPW.  What priority should I give this, though.
>>Exactly what can I do with MPW which I cannot do with CodeWarrior or
>>SC++?
>
>       The MPW compilers are so out-of-date that unless you have old
>software developed under MPW you need to maintain, don't bother.
>
>       MPW is basically a UNIX-like command line oriented environment,
>under which you can run various UNIX-like tools.  It's useful if you
>need to build UNIX-like tools to process data as part of your
>program-building process. MPW dates from when the Mac could only run
>one program at a time, and it has its own hack for running "MPW tools"
>under its own shell.

Although I agree a little with John Nagle's intent, I strongly disagree
with his message.  Although I use Think and CodeWarrior more than MPW, MPW
is still my preferred development environment when working on large
projects.

The best thing about TPM and CodeWarrior is that they remove the need for
make files.  On small and medium sized projects, and even large projects
where only a single application is to be built, the ability to let the
environment deal with dependencies is a real blessing.

The worst thing about TPM and CodeWarrior is that remove the ability to
use custom make files.  On large projects where many loosely related
components must be built, the project-based environments are a pain.
Maybe someday these enviroments will properly support subprojects or
makefiles, but until then, MPW is still superior for this kind of
development.

As to the MPW compilers being out of date, I suppose this is true if by
"MPW compilers" you mean Apple's C, Pascal, and CFront.  However, both
Symantec and Metrowerks have provided their compilers as MPW tools, and
the hybrid MrC available on ETO 15 looks like it may be a real winner
(I've only been using it for a couple days, so it's too soon for me to
say).

Jim Lloyd
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: Sat, 13 Aug 1994 15:10:32 -0800
Organization: The Information Workshop

In article <32ipft$[e-mail]>,
[e-mail] (tfullert) wrote:

> I was given a copy of MPW 3.3 (not pirated, I was given all of the
> materials in the huge box),and have the current shell from CodeWarrior.
> I am doing all of my own work on CodeWarrior and I want to devote some
> energy to learning MPW.  What priority should I give this, though.
> Exactly what can I do with MPW which I cannot do with CodeWarrior or
> SC++?


Tim,

For one thing, you will have the privilege of compiling and easily playing
with example source code from Apple, which is quite often only available
in MPW format.

Apple is getting better at this, or perhaps it is because of the
individuals at Apple who realize that...

   "If you want programmers out there to move quickly,
    don't make them jump through the hoop of having to
    convert MPW source code to their environment."

... and have graciously provided source code ready-to-compile for all the
big-three environments.

I am in the same situation as you are -- minus MPW.

Personally, I am really pissed, because I have Symantec C++, and the
PowerPC SDK, and I also have CodeWarrior 3.5, and that adds up to a good
chunk of change and a major investment of time.

For a while there, MPW was abandoned.

But now, I have been unable to participate as an OpenDoc early adopter, or
to even take advantage of the recent develop article on OSA -- which is
critical to my work -- just because I can't afford to purchase MPW, who's
price just went up to $450 the other day.

It makes my head spin.  I want to smash something.

I have always felt that all would-be Mac developers should be alerted that
it is not realistic to undertake developing software for the Macintosh
without having a minimum of $10,000 to spend on the minimum things you
need, and at least one year to write the simplest of programs (due to the
incredible wastes of time).

I wouldn't have then gone through all this anguish, and embarrassing
myself in front of so many people ( you know... investors, friends,
parents, c.s.m.p. ).

I can't blame anyone except myself.  I know that.

Even so, the world can be a screwed up place to write Mac software in.

So much needed talent -- wasted.

<shaking head>


Mark Hanrek
The Information Workshop

- ---------------------------------------------------------
P.S.  Tim:  Keep it.  You'll need it.

+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: Sat, 13 Aug 1994 16:03:09 -0800
Organization: The Information Workshop

In article <[e-mail]>, [e-mail] (Mark
Hanrek) wrote:

> ...can't afford to purchase MPW, who's price just went up to $450

oops.  After I went to check my facts, I realized that the $350 option
still remains.

But I can save money by spending a hundred dollars more! :)


- ---------

A humorous aside...


  The rich get extra "quantity discounts".
  The poor get extra "late fees".


Crazy man, crazy.  :)


Mark Hanrek
The Information Workshop

+++++++++++++++++++++++++++

>From [e-mail] (Spencer Low)
Date: Sat, 13 Aug 1994 20:15:26 -0800
Organization: LowTek Creations

In article <[e-mail]>,
mclow@san_marcos.csusm.edu (Marshall Clow) wrote:
>    Try this in CodeWarrior (or Think, for that matter). Build an
> application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in
> tools, putting the 'CODE' resources and the xDEF resources in a file of...
[more incredibly complex make stuff deleted :-]

Isn't this possible to do with ToolServer and some of the MPW tools? Or
does it get even more complex then?

(The worse I've had to do is to get AppleScript to talk to ToolServer to
Rez some files (with a special MPW/ToolServer script), open up my CW
project, link and make it, etc.)

Thanks,
Spencer
________________________________________________________________________
  Spencer "MaxRAM" Low ------ LowTek Creations ----- [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Joseph Nathan Hall)
Date: Sat, 13 Aug 94 22:20:46 MST
Organization: 5 Sigma Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (John Nagle) writes:
) [e-mail] (tfullert) writes:
) >I was given a copy of MPW 3.3 (not pirated, I was given all of the
) >materials in the huge box),and have the current shell from CodeWarrior.
) > I am doing all of my own work on CodeWarrior and I want to devote some
) >energy to learning MPW.  What priority should I give this, though.
) >Exactly what can I do with MPW which I cannot do with CodeWarrior or
) >SC++?
)
)        The MPW compilers are so out-of-date that unless you have old
) software developed under MPW you need to maintain, don't bother.
)
)        MPW is basically a UNIX-like command line oriented environment,
) under which you can run various UNIX-like tools.  It's useful if you
) need to build UNIX-like tools to process data as part of your
) program-building process. MPW dates from when the Mac could only run
) one program at a time, and it has its own hack for running "MPW tools"
) under its own shell.

Yeah, it's a bummer when a tool dies, since it takes the shell with it.
Oh, well.

But anyway, yes, the compilers are slow and have some inappropriately
glib error messages that become less funny at 4 in the morning.  However,
there is no equivalent to MPW make in either TPM or CW.  Applescripts
are a somewhat awkward alternative, I guess, but for those of us who have
special needs (yacc-generated sources, or perhaps some inputs generated
by a perl script), MPW is basically the only way to automate the building
of complex projects.  I think that you will find many commercial developers
using MPW to build auxiliary stuff even if they don't use it for compiles
in general.

Also, MPW gives you input redirection and piping for tools, which is handy
and not available otherwise.

The word from Apple, which I will take under advisement, is that the
compilers are scheduled for a rev for speed later this year.

=============== O Fortuna, velut Luna, statu variabilis ===============
uunet!joebloe!joseph   [phone] day   [e-mail]
1400 N Alma School                #163               Chandler, AZ 85224
Copyright 1994 by Joseph N. Hall.            Commercial use prohibited.
    "The division-WINNING Phillies!" -- Section 236, Row 08, Seat 03
                      (well, those were the days)

+++++++++++++++++++++++++++

>From [e-mail] (Chris Wysocki)
Date: Sun, 14 Aug 1994 07:41:37 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>,
Mark Hanrek <[e-mail]> wrote:

>I have always felt that all would-be Mac developers should be alerted that
>it is not realistic to undertake developing software for the Macintosh
>without having a minimum of $10,000 to spend on the minimum things you
>need, and at least one year to write the simplest of programs (due to the
>incredible wastes of time).

Mark, would you care to enlighten all of us as to exactly how you
arrived at this $10,000 figure?  I personally have been programming
the Macintosh since 1985, and over the course of these nine years I
have not spent a combined $10k on all the development tools, books,
documentation and other resources that I have purchased, and I own a
fairly complete library of Macintosh development tools.  Today anyone
can go out and buy Code Warrior Bronze for $99, THINK Reference for
$50, the new Inside Macintosh CD for $99, a subscription to develop
for $30, and a few good tutorial books for $200, and they'll have an
excellent set of tools for learning how to program the Macintosh, all
for less than $500.  One certainly could easily spend far more than
this, but saying that $10k is needed to start programming the
Macintosh is akin to saying that one must purchase a $90,000 BMW 850iL
in order to learn how to drive a car.

Chris.


+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Sun, 14 Aug 94 11:45:04 BST
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), mclow@san_marcos.csusm.edu (Marshall Clow) writes:

>    Try this in CodeWarrior (or Think, for that matter). Build an
> application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in
> tools, putting the 'CODE' resources and the xDEF resources in a file of
> type 'APPL', while each of the tools goes in a seperate file. Don't forget
> to put the build date (and time) into the 'vers' resource so that testers
> can tell exactily what they have. After you have built the application,
> compress the resources in the application.
>
> Oh yes, do this by choosing a single menu option.

Never mind that - just building a fat PPC/68K application with CW is a
pain in the nether regions. With CW you have to maintain 2 separate
projects, one for 68K, one for PPC. With MPW, I have 1 makefile to look
after.

Another thing that gets me with the CW/Think approach is that you must
include all of the srcs files for TCL, MacApp, PowerPlant, whatever
into your project if you want symbolic debugging of the libs. That
means a copy of the lib (with symbols) for every project that uses the
class lib. OK, so 1 GB disks are ten a penny these days. But when I get
a new release of TCL, MacApp, or whatever, it means recompiling every
TC/CW project that uses these libs. So if you have 10 projects that
use, say, MacApp, that means recompiling MacApp 10 times. With MPW, I
recompile the class lib once, build a library, then relink; at most I
only have to recompile my srcs (because of header changes). Much more
civilized.

Luckily, from CW 3.5 on, I have the best of both worlds.

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Vincent Partington)
Date: 14 Aug 1994 15:20:23 GMT
Organization: FWI, University of Amsterdam

[e-mail] (Spencer Low) writes:

>Isn't this possible to do with ToolServer and some of the MPW tools? Or
>does it get even more complex then?

I've written a small MPW Tool that can send a "Make Project" event to the
CodeWarrior environment. I use a makefile for stuff that needs to be built
by MPW Tools (Rez, Flex, Bison) and a CW project for the C code.
I type the following in the ToolServer window to have everything updated
automatically:
Make >__commands
__commands
delete __commands
MPWMake

O yeah, the tool doesn't need AppleScript to do this. Funnily enough I got CW4
yesterday and it contains some sample code to send AppleEvents to the CW
environment.
Anyway the source can be gotten by fingering [e-mail].

Vincent.
--
appel peer banaan baksteen           ||| The Fingerware Project:
schelp zon zand rolstoel             ||| Put your code snippets in your .plan!
groen wit geel flatgebouw            ||| If you want to know more
boer postbode bouwvakker roos        ||| finger [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Sun, 14 Aug 94 18:19:05 GMT
Organization: The Pitt, Chemistry

In Article <[e-mail]>, [e-mail] (Mark
Hanrek) wrote:

>Personally, I am really pissed, because I have Symantec C++, and the
>PowerPC SDK, and I also have CodeWarrior 3.5, and that adds up to a good
>chunk of change and a major investment of time.
>
>For a while there, MPW was abandoned.
>
>But now, I have been unable to participate as an OpenDoc early adopter, or
>to even take advantage of the recent develop article on OSA -- which is
>critical to my work -- just because I can't afford to purchase MPW, who's
>price just went up to $450 the other day.


    Not sure if this helps (you might be talking about the Apple
      compilers), but there is a fully configured version of the MPW
      shell for use with CW on CW4 - I think it was there for 3.5 too.




     Interet: [e-mail]         _/   _/  _/  _/_/_/   _/   _/
      eWorld: nick                 _/_/ _/  _/  _/   _/  _/_/_/
         CIS: 71232,766           _/ _/_/  _/  _/       _/ _/
                                 _/   _/  _/   _/_/_/  _/   _/

           "Science is nothing but perception" - Plato


+++++++++++++++++++++++++++

>From Ken Prehoda <[e-mail]>
Date: 14 Aug 1994 21:29:19 GMT
Organization: Univ of Wisc-Madison

In article <[e-mail]>
nick.c, [e-mail] writes:
>    Not sure if this helps (you might be talking about the Apple
>      compilers), but there is a fully configured version of the MPW
>      shell for use with CW on CW4 - I think it was there for 3.5 too.

I think Mark was talking about the MPW compilers, since he said he
has codewarrior AND the PPC SDK, both of which contain the MPW 3.3
shell.

Currently, MPW C++ is pretty much required to do build opendoc part
editors.  I, and I'm sure many others, are waiting for the opendoc
beta (that uses SOM instead of ASLM) so we can use MW C++ (or
Symantec).

However, there is a folder on the OpenDoc A6 CD for building opendoc
with codewarrior which can get you a long way until the beta arrives.

-Ken Prehoda
[e-mail]

+++++++++++++++++++++++++++

>From Gavriel State <[e-mail]>
Date: 14 Aug 1994 18:36:49 GMT
Organization: Metrowerks Inc.

In article <[e-mail]> Sak Wathanasin,
[e-mail] writes:
> Another thing that gets me with the CW/Think approach is that you must
> include all of the srcs files for TCL, MacApp, PowerPlant, whatever
> into your project if you want symbolic debugging of the libs. That

In CW4 you can debug PPC shared libraries in source.  Just build MacApp,
Powerplant, or whatever as a shared library, include it in your project,
and go.

--
 Gavriel State | 4A Systems Design Engineering/Economics | Univ. of Waterloo
- ---------------------------------------------------------------------------
Email: [e-mail]    | "Sentence fragment.  Another.  Good device.
- ------------------------------|   Will be used more later." - This is the
 Metrowerks CodeWarrior Pascal  |   title of the story, which is also found
Co-Op Engineering Student Person|      several times in the story itself.

+++++++++++++++++++++++++++

>From [e-mail] (Chris Magnuson)
Date: 15 Aug 1994 04:07:20 GMT
Organization: HP Colorado Springs Division

Chris Wysocki ([e-mail]) wrote:
: In article <[e-mail]>,
: Mark Hanrek <[e-mail]> wrote:

<snip snip>
: Mark, would you care to enlighten all of us as to exactly how you
: arrived at this $10,000 figure?  I personally have been programming
: the Macintosh since 1985, and over the course of these nine years I
: have not spent a combined $10k on all the development tools, books,
: documentation and other resources that I have purchased, and I own a
: fairly complete library of Macintosh development tools.  Today anyone
: can go out and buy Code Warrior Bronze for $99, THINK Reference for
: $50, the new Inside Macintosh CD for $99, a subscription to develop
: for $30, and a few good tutorial books for $200, and they'll have an
: excellent set of tools for learning how to program the Macintosh, all
: for less than $500.  One certainly could easily spend far more than
: this, but saying that $10k is needed to start programming the
: Macintosh is akin to saying that one must purchase a $90,000 BMW 850iL
: in order to learn how to drive a car.

  Well, you forgot to buy a Mac for one thing. :)

  Chris Magnuson
  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Mon, 15 Aug 1994 14:30:46 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>,
[e-mail] wrote:

>Yeah, it's a bummer when a tool dies, since it takes the shell with it.
>Oh, well.

The tool has to die pretty badly for "g sysrecover" to fail.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Mon, 15 Aug 1994 14:33:32 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <spencerl-130894201526@DialupNewsWatcher>, [e-mail]
(Spencer Low) wrote:

>Isn't this possible to do with ToolServer and some of the MPW tools? Or
>does it get even more complex then?

I've built things in MPW that would make your hair curl.  Specifically
trying to hack MW or TPM to build something as complicated as LabMaster
would have been defeating the point of these environments.  Use the right
tools for the job.  If you're building an application then using MW or
TPM.  If you're building something hideous then MPW is your friend.

Besides [warning, holy way bait!] MPW's editor is *sooo* much better than
any other editor on the Mac.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Tom Emerson)
Date: 15 Aug 1994 11:41:55 GMT
Organization: Symantec Development Tools Group

In article <[e-mail]>,
[e-mail] (Quinn "The Eskimo!") wrote:

> Besides [warning, holy way bait!] MPW's editor is *sooo* much better than
> any other editor on the Mac.

So, what features of the MPW editor do you prefer over those provided by
any other editor?

   -tre

--
Tom Emerson                                              Software Engineer
Development Tools Group                               Symantec Corporation
                          [e-mail]
  "I dreamed I had to take a test, in a Dairy Queen, on another planet."

+++++++++++++++++++++++++++

>From [e-mail] (Neal Trautman)
Date: 15 Aug 1994 14:04:01 GMT
Organization: Farallon Computing, Inc.

In article <[e-mail]>, mclow@san_marcos.csusm.edu (Marshall Clow) writes:
>
>    Try this in CodeWarrior (or Think, for that matter). Build an
> application containing 4 LDEFs, 2 MDEFs, 3 WDEFs, as well as 12 plug in
> tools, putting the 'CODE' resources and the xDEF resources in a file of
> type 'APPL', while each of the tools goes in a seperate file. Don't forget
> to put the build date (and time) into the 'vers' resource so that testers
> can tell exactily what they have. After you have built the application,
> compress the resources in the application.
>
> Oh yes, do this by choosing a single menu option.
>

I agree.  Timbuktu has two applications, a Desk Accessory,
an Extension with an INIT, a DRVR and stand-alone code resources,
an AOCE catalog template, an Installer script, and two help files.
Most all of these files are also compressed.

AND, I can build all this in 4 languages (English, French, German,
and Kanji) by selecting one menu command.

Now, on the other hand, for the Metroweks Profiler viewer application,
I used CodeWarrior and PowerPlant there was only one piece to build.

==========================================================================
Neal Trautman                          I climbed to the top of the ladder
Timbuktu Lead Software Engineer          of success only to realize it was
Metrowerks CodeWarrior Profiler co-author  leaning against the wrong wall.
==========================================================================


+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: Mon, 15 Aug 1994 09:36:04 -0800
Organization: The Information Workshop

In article <32m2bf$[e-mail]>, Ken Prehoda
<[e-mail]> wrote:

> In article <[e-mail]>
> nick.c, [e-mail] writes:
> >    Not sure if this helps (you might be talking about the Apple
> >      compilers), but there is a fully configured version of the MPW
> >      shell for use with CW on CW4 - I think it was there for 3.5 too.
>
> I think Mark was talking about the MPW compilers, since he said he
> has codewarrior AND the PPC SDK, both of which contain the MPW 3.3
> shell.
>
> Currently, MPW C++ is pretty much required to do build opendoc part
> editors.  I, and I'm sure many others, are waiting for the opendoc
> beta (that uses SOM instead of ASLM) so we can use MW C++ (or
> Symantec).
>
> However, there is a folder on the OpenDoc A6 CD for building opendoc
> with codewarrior which can get you a long way until the beta arrives.
>
> -Ken Prehoda
> [e-mail]

Thanks, Ken, for clarifying that for me.  And thanks for the reference to
that folder!

I quadruple-checked for anything to do with CodeWarrior on the A6 CD, and
found a read-me that referred to a folder that does not exist, at least on
the WWDC version of OpenDoc A6.

So, is it the case that this folder does exist on another version of the
OpenDoc A6 release?  I looked on eWorld, but those files come in clumps.
:)

Still trying...

Mark Hanrek

+++++++++++++++++++++++++++

>From mclow@san_marcos.csusm.edu (Marshall Clow)
Date: Mon, 15 Aug 1994 10:14:05 -0800
Organization: Aladdin Systems

In article <tree-1508940738330001@155.64.60.63>, [e-mail]
(Tom Emerson) wrote:

> In article <[e-mail]>,
> [e-mail] (Quinn "The Eskimo!") wrote:
>
> > Besides [warning, holy way bait!] MPW's editor is *sooo* much better than
> > any other editor on the Mac.
>
> So, what features of the MPW editor do you prefer over those provided by
> any other editor?
>

Tom --

   My _favorite_ MPW editor feature is the "double click on open
paren/brace/bracket/slash/quote and select everything up to the matching
symbol. (Also works with 2x-clicking on the closing symbol. If you hold
the mouse button down after the second click, you can move the cursor
around and see the selection change to show differing "matches"

MUCH, much better than the "Balance" command in Think.

-- Marshall
[ Who's trying to turn an potential flame war into a rational discussion. ]

--
Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu

+++++++++++++++++++++++++++

>From kenp@tuli (Kenneth Prehoda)
Date: 15 Aug 1994 18:31:25 GMT
Organization: Division of Information Technology

Mark Hanrek ([e-mail]) wrote:
: Thanks, Ken, for clarifying that for me.  And thanks for the reference to
: that folder!

: I quadruple-checked for anything to do with CodeWarrior on the A6 CD, and
: found a read-me that referred to a folder that does not exist, at least on
: the WWDC version of OpenDoc A6.

: So, is it the case that this folder does exist on another version of the
: OpenDoc A6 release?  I looked on eWorld, but those files come in clumps.
: :)

: Still trying...

: Mark Hanrek

The "Building Opendoc with Codwarrior" Folder is only on the
OpenDoc A6 with source disk, I believe (Jens, can you help
me out here?).  This is because to use codewarrior you currently
have to build your part editor inside of opendoc and hence
requires building opendoc in CW.

-Ken Prehoda
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Leon Lambert)
Date: Mon, 15 Aug 1994 17:58:53 GMT
Organization: measurex

In article <32ipft$[e-mail]>
[e-mail] (tfullert) writes:

> Hi:
>
> I was given a copy of MPW 3.3 (not pirated, I was given all of the
> materials in the huge box),and have the current shell from CodeWarrior.
>  I am doing all of my own work on CodeWarrior and I want to devote some
> energy to learning MPW.  What priority should I give this, though.
> Exactly what can I do with MPW which I cannot do with CodeWarrior or
> SC++?
>
> Thanks;
>
> Tim

I find the scripting language in MPW to be great. It takes quite an investment
to learn but really pays off if you have a lot of tedious repetative editing
to do. I do a lot of porting of code to other platforms and find it very
useful. The comparefiles script is worth its weight in Gold. I have not
found a better file comparison utility on any platform out there.

Since switching to CW I find myself spending about 85% of my time there,
but still need to switch to MPW to do some fancy stuff. MPW allows you
to hook your own functions to keys to do fancy editing. For instance
I can double click a function name and do a cmd 0 and the proper #include
is inserted at the top of my C file. I wish CW would put some sort
of scripting/macro ability into their editor.

[e-mail] (Leon Lambert)
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Tue, 16 Aug 1994 11:10:30 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <tree-1508940738330001@155.64.60.63>, [e-mail]
(Tom Emerson) wrote:

>So, what features of the MPW editor do you prefer over those provided by
>any other editor?

[On no, I'm gonna get in twubble again... (: ]

#1 most important feature... it edits arbitrary sized files.  I get
*really* annoyed when I edit a file and programs go "not enough memory to
edit this document".  But I recognise that this feature is a) hard and b)
unnecessary for programming.  It's just that MPW has it and no one else
does.

I also like the way MPW's command, option & shift arrow keys all seem to
work they way I expect.  And, if worst comes to worst, I can use SetKey to
fix them (:

Double-clicking on brackets to match them!  [Although that's supposed to
have arrived in CW4.]

I *really* like MPW's search and replace system, especially the way that
shift works to search backwards.  I just can't get the the hang of any
Think editor's search and replace.  CW is good but the non-modal dialog
just confuses me (:  I also like the power of MPW's regular expressions.
[And unlike most of my unix-raised bretheren, I understand them better
than unix regexs.]

I also make quite a bit of use adding scripts into menus.

I suspect that Alpha provides most of the flexibility that I need in an
editor.  But unfortunately Alpha is both ugly (IMHO of course) and Dvorak
keyboard unfriendly.  [Yes I know you can tweak it but that's *no*
excuse.]

I want MPW's editor ripped out of MPW so that I can use it with CW and TPM
without blowing away multiple megabytes!!!  We have ToolServer and
SourceServer, why not EditorServer (:

Share and Enjoy.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  Who's just come from one flame war in c.s.m.hardware and doesn't
  really want to start another here ):

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Tue, 16 Aug 1994 16:24:50 +1200 (NZST)
Organization: (none)

mclow@san_marcos.csusm.edu (Marshall Clow) writes:
>    My _favorite_ MPW editor feature is the "double click on open
> paren/brace/bracket/slash/quote and select everything up to the matching
> symbol. (Also works with 2x-clicking on the closing symbol. If you hold
> the mouse button down after the second click, you can move the cursor
> around and see the selection change to show differing "matches"
>
> MUCH, much better than the "Balance" command in Think.

Holy cow!

I've been using MPW since 1987, and have used the "double-click on a bracket"
feature forever, but I've never discovered the "hold the button down"
feature.

Cool!

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Stephen F Coy)
Date: 16 Aug 1994 10:23:29 GMT
Organization: Microplex Pty Ltd

Quinn "The Eskimo! ([e-mail]) wrote:
: In article <tree-1508940738330001@155.64.60.63>, [e-mail]
: (Tom Emerson) wrote:

: >So, what features of the MPW editor do you prefer over those provided by
: >any other editor?

: [On no, I'm gonna get in twubble again... (: ]

: #1 most important feature... it edits arbitrary sized files.  I get
: *really* annoyed when I edit a file and programs go "not enough memory to
: edit this document".  But I recognise that this feature is a) hard and b)
: unnecessary for programming.  It's just that MPW has it and no one else
: does.

: I also like the way MPW's command, option & shift arrow keys all seem to
: work they way I expect.  And, if worst comes to worst, I can use SetKey to
: fix them (:

: Double-clicking on brackets to match them!  [Although that's supposed to
: have arrived in CW4.]

: I *really* like MPW's search and replace system, especially the way that
: shift works to search backwards.  I just can't get the the hang of any
: Think editor's search and replace.  CW is good but the non-modal dialog
: just confuses me (:  I also like the power of MPW's regular expressions.
: [And unlike most of my unix-raised bretheren, I understand them better
: than unix regexs.]

: I also make quite a bit of use adding scripts into menus.

: I suspect that Alpha provides most of the flexibility that I need in an
: editor.  But unfortunately Alpha is both ugly (IMHO of course) and Dvorak
: keyboard unfriendly.  [Yes I know you can tweak it but that's *no*
: excuse.]

: I want MPW's editor ripped out of MPW so that I can use it with CW and TPM
: without blowing away multiple megabytes!!!  We have ToolServer and
: SourceServer, why not EditorServer (:

: Share and Enjoy.
: --
: Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
: Department of Computer Science, The University of Western Australia
:   Who's just come from one flame war in c.s.m.hardware and doesn't
:   really want to start another here ):

I could not have said this better myself. In fact, one of the reasons I
like Object Master so much is that it emulates (mostly anyway) the
keyboard and search/replace behaviour of MPW. Everytime I fire up the
Symantec C++ IDE, the editor drives me nuts in short order.


- ------
Steve Coy
Resolve Software (WA) Pty Ltd
Sydney Australia


+++++++++++++++++++++++++++

>From Willie Abrams <[e-mail]>
Date: 16 Aug 1994 13:21:15 GMT
Organization: OU Health Sciences Center

In article <tree-1508940738330001@155.64.60.63> Tom Emerson,
[e-mail] writes:
>So, what features of the MPW editor do you prefer over those provided by
>any other editor?

Tom, hate to make a pointed remark...MPW can open up files
to just look at and edit individually (unlike TPM, where I can't
unless I have a project open.)

It is a small, but modal inconvenience that keeps me from even
going to TPM look at hardly any source files - I find myself
dragging and dropping on to BBEdit Lite.

Willie Abrams                                  [e-mail]
Telemedicine Software Guy                     OU Health Sciences Center

It's a classic Pincer's Movement. It can't fail against a ten-year-old!

+++++++++++++++++++++++++++

>From Willie Abrams <[e-mail]>
Date: 16 Aug 1994 13:22:35 GMT
Organization: OU Health Sciences Center

In article <[e-mail]>
Quinn, [e-mail] writes:
>unnecessary for programming.  It's just that MPW has it and no one else
>does.

BBEdit hardly ever has this problem...

Willie Abrams                                  [e-mail]
Telemedicine Software Guy                     OU Health Sciences Center

It's a classic Pincer's Movement. It can't fail against a ten-year-old!

+++++++++++++++++++++++++++

>From [e-mail] (Tom Emerson)
Date: Tue, 16 Aug 1994 15:30:56 -0500
Organization: Symantec Development Tools Group

In article <32qegb$[e-mail]>, Willie Abrams
<[e-mail]> wrote:

> In article <tree-1508940738330001@155.64.60.63> Tom Emerson,
> [e-mail] writes:
> >So, what features of the MPW editor do you prefer over those provided by
> >any other editor?
>
> Tom, hate to make a pointed remark...MPW can open up files
> to just look at and edit individually (unlike TPM, where I can't
> unless I have a project open.)

Sure, I understand. But that is an environment issue, not an editor issue.
Just picking nits ;-) This is something that is, contrary to many peoples
belief, something that is non-trivial to change in the design of the TPM,
not that it hasn't been discussed. Who knows what the future may hold,
though.

   -tre

--
Tom Emerson                                              Software Engineer
Development Tools Group                               Symantec Corporation
                          [e-mail]
  "I dreamed I had to take a test, in a Dairy Queen, on another planet."

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Wed, 17 Aug 1994 10:12:19 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <32qeir$[e-mail]>, Willie Abrams
<[e-mail]> wrote:

>BBEdit hardly ever has this problem...

Yeah, I know, BBEdit uses temporary memory.  But it still bites me.  I
only have 20MB (: and when I'm programming and documenting XCMDs I need
MPW, HyperCard and my documentation tools open all at once which means
that I regularly run out of temporary memory.  Then I got to poke around
in a PostScript file at the same time...

Just one of those inconveniences that I can do without.  And given the
other advantages of MPW's editor.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  And don't even mention LabView.

+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: Wed, 17 Aug 1994 07:35:44 GMT
Organization: Ibex Productions

In article <32qeir$[e-mail]> Willie Abrams, [e-mail]
writes:
>Quinn, [e-mail] writes:
>>unnecessary for programming.  It's just that MPW has it and no one else
>>does.
>
>BBEdit hardly ever has this problem...

Actually, I was dealing with Postscript files a while back, and MPW
is the only editor (besides MS Word) that would open them - no matter
how big (ie: a couple of megs). Of course, I could have changed
BBEdit's partition size, but I use it as my 'normal' editor
and wouldn't want to keep changing it.

BBEdit's major strength, IMO, is its multi-file search browser.
Too bad you can't edit in it, though.

+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: Wed, 17 Aug 1994 07:43:10 GMT
Organization: Ibex Productions

In article <32ipft$[e-mail]> tfullert,
[e-mail] writes:
>Exactly what can I do with MPW which I cannot do with CodeWarrior or
>SC++?

Well, there are three main things:

(1) you can do a multitude of incredibly complicated things with MPW's
scripting language/makefiles. In essence, you have complete control
over the shell, and can issue commands, etc.

(2) you can have completely integrated projector support (how many
times have you moved a ProjectorDB file and gotten the "can't check in
file blah because the project was not found" using the TPM/SS combo?
This never happens w/Projector. Plus, check in active/check out active
work, and the checkin window doesn't take forever in MPW.)

(3) You can be macho <-- arguably the most important thing you can't do
                         if you use CW/SymC

+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: Wed, 17 Aug 1994 07:46:44 GMT
Organization: Ibex Productions

In article <[e-mail]> Quinn,
[e-mail] writes:
>>Yeah, it's a bummer when a tool dies, since it takes the shell with it.
>>Oh, well.
>
>The tool has to die pretty badly for "g sysrecover" to fail.

You can also use "g stoptool". I'm not sure which one's recommended, though.

+++++++++++++++++++++++++++

>From bix.com!dvanhoozer
Date: 17 Aug 1994 08:53:26 GMT
Organization: Mad Bomber Software

In article <[e-mail]> [e-mail] (Bruce
Hoult) writes:
>mclow@san_marcos.csusm.edu (Marshall Clow) writes:
>> the mouse button down after the second click, you can move the cursor
>> around and see the selection change to show differing "matches"
>>
>> MUCH, much better than the "Balance" command in Think.
>
>Holy cow!
>
>I've been using MPW since 1987, and have used the "double-click on a bracket"
>feature forever, but I've never discovered the "hold the button down"
>feature.

My face is just as red BH, like you that one has some how
got past me.  I wonder what else I don't know....   :-)

Dewayne
  o-*



+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Thu, 18 Aug 1994 03:17:32 +1200 (NZST)
Organization: (none)

Manuel Veloso <[e-mail]> writes:
> Actually, I was dealing with Postscript files a while back, and MPW
> is the only editor (besides MS Word) that would open them - no matter
> how big (ie: a couple of megs). Of course, I could have changed
> BBEdit's partition size, but I use it as my 'normal' editor
> and wouldn't want to keep changing it.

BBEdit lets you open any size file without changing the partition
size -- it uses System memory.

In my moonlighting job as a consultant to a DTP company, I often use
BBEdit to edit PostScript files of up to 80 or 100 MB in size.  It
handles it without a complaint, with very good performance (once the
file is all read into memory), in the standard BBEdit memory partition.

MPW and Word simply can't cope with files this size with any sort of
performance at all.  You done good, Rich.

This *is* on a Q950 with 136 MB of RAM, mind you.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Mel Martinez)
Date: Wed, 17 Aug 1994 15:57:25 -0500
Organization: The Johns Hopkins Univ. - Dept. of Physics

In article <[e-mail]>, [e-mail]
(Bruce Hoult) wrote:

> Manuel Veloso <[e-mail]> writes:
> > Actually, I was dealing with Postscript files a while back, and MPW
> > is the only editor (besides MS Word) that would open them - no matter
> > how big (ie: a couple of megs). Of course, I could have changed
> > BBEdit's partition size, but I use it as my 'normal' editor
> > and wouldn't want to keep changing it.
>
> BBEdit lets you open any size file without changing the partition
> size -- it uses System memory.
>
> In my moonlighting job as a consultant to a DTP company, I often use
> BBEdit to edit PostScript files of up to 80 or 100 MB in size.  It
> handles it without a complaint, with very good performance (once the
> file is all read into memory), in the standard BBEdit memory partition.
>
> MPW and Word simply can't cope with files this size with any sort of
> performance at all.  You done good, Rich.
>
> This *is* on a Q950 with 136 MB of RAM, mind you.
>
> -- Bruce


Err.. thank you.  You may sit down now, please.  :-)

Now back to dealing with problems for 'the rest of us' (with single &
double digit memory)...

Sheesh!

Mel

+++++++++++++++++++++++++++

>From [e-mail] (Rich Siegel)
Date: Wed, 17 Aug 1994 19:36:24 GMT
Organization: Bare Bones Software

In article <[e-mail]> [e-mail] (Bruce Hoult) writes:
>In my moonlighting job as a consultant to a DTP company, I often use
>BBEdit to edit PostScript files of up to 80 or 100 MB in size.  It
>handles it without a complaint, with very good performance (once the
>file is all read into memory), in the standard BBEdit memory partition.
>
>MPW and Word simply can't cope with files this size with any sort of
>performance at all.  You done good, Rich.

I appreciate the compliment, but in good conscience can't take -all-
the credit. The text engine was original written by Jon Hueras, with
modifications by me, and Jon also did the rewrite for PowerPC.

(That won't stop me from taking -some- of the credit, though. :-])

R.
--
Rich Siegel % [e-mail]    % President & CEO, Bare Bones Software Inc.
--> For information about BBEdit, finger [e-mail] <--

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 17 Aug 1994 13:43:17 -0700
Organization: SRI International, Menlo Park, CA

In article <tree-1608941530560001@155.64.60.63> [e-mail] (Tom Emerson) writes:

>Sure, I understand. But that is an environment issue, not an editor issue.
>Just picking nits ;-) This is something that is, contrary to many peoples
>belief, something that is non-trivial to change in the design of the TPM,
>not that it hasn't been discussed. Who knows what the future may hold,
>though.

We have seen the future (rainbow that is) and you better hurry
up and make it so or else you won't have a market left.


Xavier






--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 19 Aug 94 16:05:30 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <tree-1508940738330001@155.64.60.63>, [e-mail] (Tom Emerson) writes:
> In article <[e-mail]>,
> [e-mail] (Quinn "The Eskimo!") wrote:
>
>> Besides [warning, holy way bait!] MPW's editor is *sooo* much better than
>> any other editor on the Mac.
>
> So, what features of the MPW editor do you prefer over those provided by
> any other editor?

Of course, one of the things that gets me waxing so lyrical is that MPW is
so much more than just an editor.

On more than one occasion now, I've been involved in upgrading our
departmental AppleShare server. We've been through 2-3 hard disk upgrades
and one change of machine over the past couple of years. Each time, of course,
I've had to copy all the files from the old hard disk to the new one, and
preserve all their folder protections. I've never bothered getting any
proper backup software to do this, since I've made it quite clear to our users
that they have to back up their own data, all I'm responsible for is the
server configuration itself.

The file-copying part was never a big deal: I just drag everything across
in the Finder, and leave it copying for a few hours, or overnight, or whatever.
For transferring the folder protections (and for backing them up), I use MPW.

The MPW Shell has this neat convention in some commands: it uses the same
command for both examining a setting and for changing it. The clever thing is,
when you ask the command to display the existing setting, it outputs a command
which can be used to set the setting to that value. For example, the
SetPrivilege tool lets you examine and change folder protections. The command
"SetPrivilege -i" displays the current protections in the form of "SetPrivilege"
commands. So to dump out all the existing protections on the old volume, I
issued the command:

    SetPrivilege -i -r "OldVolume:"

(the -r option says to recursively list subfolders as well). Then I did a
global search and replace on the output, replacing all occurrences of OldVolume
with NewVolume, and finally I selected the result and pressed Enter to
execute it. Voila! All the protections transferred with a minimum of work.

As I keep saying, if you can't do it with MPW, it isn't worth doing. :-)

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 19 Aug 1994 23:32:41 GMT
Organization: Apple Computer

Kenneth Prehoda, kenp@tuli writes:
> The "Building Opendoc with Codwarrior" Folder is only on the
> OpenDoc A6 with source disk, I believe (Jens, can you help
> me out here?).  This is because to use codewarrior you currently
> have to build your part editor inside of opendoc and hence
> requires building opendoc in CW.

You're 100% right. I guess it might have been possible to precompile all the
OD code into a library that you'd link into an app along with your part
implementation, but I didn't have time to do that.

Of course the beta release will work fine with CodeWarrior (in fact that's
what we do our primary development with now, with brief excursions to MPW to
run the SOM compiler.)

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 21 Aug 1994 14:58:28 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <tree-1608941530560001@155.64.60.63>, [e-mail]
(Tom Emerson) wrote:

>This is something that is, contrary to many peoples
>belief, something that is non-trivial to change in the design of the TPM [...]

Working as designed ):
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
>From [e-mail] (eric larson)
Subject: What is the point of MPW?
Date: 18 Aug 94 19:11:49 -
Organization: FidoNet: Shockwave Rider, USR V.Everything [phone]

 >>MPW and Word simply can't cope with files this size with any sort of
 >>performance at all.  You done good, Rich.

 > I appreciate the compliment, but in good conscience can't take -all-
 > the credit. The text engine was original written by Jon Hueras, with
 > modifications by me, and Jon also did the rewrite for PowerPC.

I've had similar experiences with BBEdit. When making literally thousands of
changes using search and replace on a 10 MB text file, every other editor I've
tried chokes. BBEdit handles the job smoothly, without complaint.

+++++++++++++++++++++++++++

>From [e-mail] (Judy Ann Kettenhofen)
Date: 28 Aug 1994 21:52:51 GMT
Organization: Portal Communications Company -- 408/973-9111 (voice) 408/973-8091 (data)

eric larson ([e-mail]) wrote:
:  >>MPW and Word simply can't cope with files this size with any sort of
:  >>performance at all.  You done good, Rich.

:  > I appreciate the compliment, but in good conscience can't take -all-
:  > the credit. The text engine was original written by Jon Hueras, with
:  > modifications by me, and Jon also did the rewrite for PowerPC.

: I've had similar experiences with BBEdit. When making literally thousands of
: changes using search and replace on a 10 MB text file, every other editor I've
: tried chokes. BBEdit handles the job smoothly, without complaint.

Sorry, I didn't see the first part of this message.
In general, MPW should have problems with large files in two cases:
1) Where there are a large number of markers
2) Where you make a lot of changes.

For the first, you are out of luck, to the best of my knowledge.
For the second, you can do some things to help.
1. Save your file frequently after changes.
   This helps MPW Shell to basically do garbage collection, and
   requires less of the file to be resident in memory.
2. There is a way to change the size of the editor heap.
   I don't recall what it is right now.  If you know you
   are going to have large files, you can try enlarging the editor heap.
The MPW Shell has code to create subsequent editor heaps if it runs
out of space in the first one, but I don't think that code has been
exercised much.

--Judy

--former MPW hack.


+++++++++++++++++++++++++++

>From dlopez@sailsun (Dean Lopez)
Date: 30 Aug 1994 13:00:34 GMT
Organization: NASA Johnson Space Center, Houston, TX, USA

eric larson ([e-mail]) wrote:
> I've had similar experiences with BBEdit. When making literally thousands of
> changes using search and replace on a 10 MB text file, every other editor I've
> tried chokes. BBEdit handles the job smoothly, without complaint.

I just started using BBEdit Lite (v2.3? - whatever the latest rev is), and I've
noticed whenever I open an existing file, BBEdit promptly puts a single
garbage character at the end of my file.  It doesn't mark the file as 'dirty'
though, so if I close the file, the garbage character doesn't get saved to
the file.  If I make any edits to the file and THEN save, the garbage character
ends up at the end of my file, which promptly causes my compiler to complain.
Has anyone had this problem with the commercial BBEdit?
--
+--------------------------------------+------------------------------+
| Dean Lopez                           |                              |
| SAIL DPS Engineer                    | [e-mail]  |
| Rockwell Space Operations Co.        | [e-mail]            |
| JSC Shuttle Avionics Integration Lab | [e-mail] |
+--------------------------------------+------------------------------+
#include <standard_disclaimer.h>
/* The opinions expressed are all mine.
   RSOC doesn't speak for me and I don't speak for RSOC
   After all, I'm only an engineer - what do I know?     */

---------------------------

>From netcom.com!kira!davidjohn (David John Burrowes)
Subject: Where have the standards gone? [a high level question]
Date: Fri, 19 Aug 1994 03:17:20 GMT
Organization: No organization at this time.

I was reading the article about System 7.5 in the September 1994 issue of
MacUser (p. 79-84), and it raised a gigantic question in my mind.  After
some thought, I decided to see what opinions others (yourselves) might have.

The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several
new features of this system software release.  In them, I noted five new
window styles:
- a strange little thing for 'post-it' notes
- a green one for the CD player (the title bar is similar to the standard
  document titlebar, but not the same)
- the Find File windows have a funky styled background
- the Launcher window gives us a window with, presumably, a standard pink
  background with square/tile/chicklet(sp?) icons
- A window that is reminiscent of the 'palette' titlebar, but with close
  and zoom boxes.
(the TV stuff in another article has yet another window style variation).

For buttons, I notice these new styles (in *addition* to standard flat Mac
push-buttons)
- '3D' buttons in the Launcher window,
- two types of CD player-like buttons in the CD player window (also found on
  the TV control panel in that other article)
- plus, two other '3D' styles for the help system (one with icons, and
  one that looks like 'shallow' buttons at the bottom of the
  palette-ish windows.
(plus, what looks like another '3d'ish style is seen in the TV control
panel)

Individually, many of these don't look that bad, I suppose (but, that's
another issue, really).  However, as I recall, one of the advertised
strengths of the Macintosh, in past years, was its highly consistent
interface.  Buttons looked and behaved the same everywhere.  Windows with a
particular style almost always behaved the same as other windows with the
same style.  Etc.
I find myself concerned, therefore, with all of these new innovations.  I do
not see a great deal of consistency here.  What kind of message is this
sending to developers? It seems to me it's something like, 'Sure, go ahead,
bypass the toolbox (as I assume some or much of the above stuff is). Make up
whatever non-standard user interface features you want so your app looks
unusual and snazzy. Users will figure it out eventually.'
Sure, I know, some developers have always felt compelled to do things their
own way.  But, since this is Apple doing non-standard things, many more
people will feel justified in going off and doing *their own* things.  By
itself, I find this to be a depressing prospect.  But, with Microsoft coming
out with a significantly improved user interface for Windows soon (Chicago),
this all strikes me as Apple shooting itself in the foot, bigtime, which I
find more depressing still.

If you've read this far, I'm curious what your thoughts are, either through
personal email or on the newsgroup.  Maybe I'm very much in the minority,
and folks generally think the 'highly consistent' interface was too
constraining?

Thanks.

david john burrowes
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Chris Wysocki)
Date: Fri, 19 Aug 1994 09:51:10 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>,
David John Burrowes <netcom.com!kira!davidjohn> wrote:

>I find myself concerned, therefore, with all of these new innovations.  I do
>not see a great deal of consistency here.  What kind of message is this
>sending to developers? It seems to me it's something like, 'Sure, go ahead,
>bypass the toolbox (as I assume some or much of the above stuff is). Make up
>whatever non-standard user interface features you want so your app looks
>unusual and snazzy. Users will figure it out eventually.'
>Sure, I know, some developers have always felt compelled to do things their
>own way.  But, since this is Apple doing non-standard things, many more
>people will feel justified in going off and doing *their own* things.  By
>itself, I find this to be a depressing prospect.  But, with Microsoft coming
>out with a significantly improved user interface for Windows soon (Chicago),
>this all strikes me as Apple shooting itself in the foot, bigtime, which I
>find more depressing still.

I wholeheartedly concur.  Apple has done far too little in recent
years to promote UI consistency across applications.  Their reluctance
to provide standard implementations of UI features such as floating
windows, menus with multiple-modifier keyboard shortcuts, and basic
controls such as up-down arrows, sliders and progress bars have forced
developers to implement these features themselves, with varying and
sometimes inconsistent results.  At the Worldwide Developers
Conference in May some Apple engineers spoke in nebulous terms about
future UI enhancements which are coming down the road, but it struck
me and others with whom I spoke as too little, too late....

Chris.

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Fri, 19 Aug 1994 11:11:19 GMT
Organization: Process Control Center

In article <[e-mail]>,
netcom.com!kira!davidjohn (David John Burrowes) wrote:

> I was reading the article about System 7.5 in the September 1994 issue of
> MacUser (p. 79-84), and it raised a gigantic question in my mind.  After
> some thought, I decided to see what opinions others (yourselves) might have.
>
> The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several
> new features of this system software release.  In them, I noted five new
> window styles:

[schnipp...]

> If you've read this far, I'm curious what your thoughts are, either through
> personal email or on the newsgroup.  Maybe I'm very much in the minority,
> and folks generally think the 'highly consistent' interface was too
> constraining?

I think the subject is worthy of general discussion, so I'll post; in any
case, our mail server is currently down.

It seems to me that standards are going out the window, and that this is a
negative development. Conventional buttons and WDEFs may seem a little
unadventurous, but in day-to-day work the security of knowing how to
recognize a button and where the window title is are a great advantage. I
always disliked HyperCard's anything-can-be-a-button attitude, because it
leaves you with the challenge of clicking on *everything*, just to see if
maybe that little chicklet-shaped object triggers some sort of action.
This is fine and dandy for an adventure game, but frustrating when you're
trying to get on with your work.

As one example, I was looking at the new(ish) AppleCD Audio Player. The
only reason I even tried clicking on the little green triangle in the
lower left corner was because I knew that the fore-runner software had a
track list and I was sure that the newer software _must_ have a track list
somewhere. I looked in the menus, to no avail, so I started clicking
around and the mouse finally landed on said triangle. Voila! Success at
last!

But, why the hell should I spend my time clicking around a window to find
a substitute for the Zoom box? (Use of the zoom box as a sort of
{show|hide}-details-of-a-dialog-window is not officially sanctioned, but
has found it's way into a number of utility programs). Sure, if I'd turned
on Balloon Help, I might have found this button sooner, but an experienced
Mac user shouldn't need Balloon Help to find an _Ersatz_ zoom box.

That said, let me add that it *is* important for UIs to develop; I'm not
going to advocate cast-in-platinum Human Interface Guidelines. The
_Macintosh Humand Interface Guidelines_ discuss the subject of ``Going
Beyond the Guidelines'' quite specifically.

The problem with System 7.5 seems to be that Apple has simply integrated a
couple of 3rd party extensions where graphic design went out of control,
and nobody bothered to talk with Human Interface about what was good, bad,
or useful.

There is considerable irony in this, in light of Pete Bickford's article
in the August _AppleDirections_.

Of course, if you want to see some really funky non-standard windows, look
at any of the MIDI Products coming from Mark of the Unicorn. Users cried
bloody murder when MotU introduced it's ``Miami Vice'' look, but MotU has
stayed with it. The ``Mini-Menu'' that was added to most windows are
arguably functional, but, even after using their software for several
years, I fail to recognize the advantage of a triangular close box or a
misplaced zoom box.

So, in short: yes, this bothers me. Who else?

--
Peter Castine               | In old days books were written by men of
[e-mail]   | letters and read by the public. Nowadays books
Process Control Center      | are written by the public and read by nobody.
Technical University Berlin |                                 -- Oscar Wilde

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Fri, 19 Aug 1994 08:19:17 -0500
Organization: One Step Beyond

netcom.com!kira!davidjohn (David John Burrowes) wrote:

) ...
) Individually, many of these don't look that bad, I suppose (but, that's
) another issue, really).  However, as I recall, one of the advertised
) strengths of the Macintosh, in past years, was its highly consistent
) interface.  Buttons looked and behaved the same everywhere.  Windows
) with a particular style almost always behaved the same as other windows
) with the same style.  Etc.

I wholeheartedly concur.  Apple's HIG seems to have lost its way -- either
that or they have lost their authority to override developer's and
designers taste for the strange.  One would expect that with Don Norman in
charge (he is in charge of HIG isn't he?) that HIG would be less worried
over the "look" and more about the "feel".  That they would hire fewer
graphic designers and more people versed in psychology and sociology.

For example, a few months ago there were threads here and on AppleLink
about the new windoid look used for Apple Guide.  Apple's first excuse was
that they "did research" and discovered that the de-facto standard for
floating palette title bars was too small a target.  Fine, why didn't they
simply make the de-facto standard a couple pixels taller?  Noooo, instead
then said that they hired some graphics designer (as if graphic designers
somehow are better at human interface design...).  Of COURSE they'll get
something that looks different!  Who could expect anything else?  If the
designer returned with something the same as the existing de-facto standard
he would be a braver man than most.  Hell, they could have saved hard $$$
by buying Infinity Windoid from Troy Gual.

The sticky note windows are even more bothersome.  As is the inclusion of
single-click to launch in the Launcher palette.  I've found that it takes
users time to learn the double click to launch method in the Finder, but
once they do, they understand it.  Now, IN THE SAME PROGRAM, there are
_two_ methods to open files.  This is good?

Looking farther into the future, does the pre-emption of the "File" menu
with a "Document" menu in OpenDoc bother anyone?  This seems to me to be
a gratuitous market decision in a vain attempt to differentiate" OpenDoc
from the current crop of applications.  Hogwash.  Changing the name of
"File" to "Document" only confuses people, takes up menu bar space, and
will NOT increase market share one tiny bit.  Do users a vavor, dump the
"Document" menu and the old, expected and unsuprising "File".

Consistancy and the route of least suprise are _very_ important principles
and I wish that stupid columnists would quit harping about the "tired old
Mac interface".  An interface _should_ be "boring" and "underwhelming".
It should not overwhelm the functionality of the system.  It should be
as invisible as possible.  Since computer interfaces are definately not
intuative, only through consistancy will we even approach the goal of
invisibility.

If people want funky looking buttons and windows, third party options
exist.  But at least most third party options work over all applications,
thus still providing some consistancy on that single machine.

Finally, lest anyone say that these issues should have been brought up
long ago...they were.  Both here, on AppleLink and probably other on-line
services as well.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Southwick)
Date: 19 Aug 1994 14:34:06 GMT
Organization: IBM SWSD, Lexington, KY, USA

[e-mail] (Chris Wysocki) writes:
>David John Burrowes <netcom.com!kira!davidjohn> wrote:

>>I find myself concerned, therefore, with all of these new innovations.

These new interface elements are truly surprising, since they haven't
implemented all the stuff that they should have - see below.

>....  Their reluctance
>to provide standard implementations of UI features such as floating
>windows, menus with multiple-modifier keyboard shortcuts, and basic
>controls such as up-down arrows,

"spinners", such as for the Time field in what used to be known as the
General control panel?

>sliders and progress bars have forced
>developers to implement these features themselves, with varying and
>sometimes inconsistent results.

This really (constantly) surprises me.  THIS is the part of the human
interface that APPLE should be working on.  Why do I have to create
all these controls by hand?  Why has Apple refused to develop these
interface enhancements?  They recognize that (at least some) of them
are needed, and Apple products use almost all of these (multiple-
modifiers being the one exception, correct me if you've found an Apple
product that does use them) interface methods themselves.

>At the Worldwide Developers
>Conference in May some Apple engineers spoke in nebulous terms about
>future UI enhancements which are coming down the road, but it struck
>me and others with whom I spoke as too little, too late....

I'd like to confront some Apple management types about this stuff, but
given that it's not likely, I thought I'd vent my spleen here.

>Chris.

Another poster mentions MotU's Performer - which I've seen and used (for
9 months or so).  It's something you get used to - but why should I
change my methods at all?  I use Opcode's Vision, which has a more Mac-like
interface.  It does use drop-down menus in windows.  More like pop-ups,
actually.  They drop down from icons - but the icons have drop shadows.
A more consistent Mac-like interface, and rather than being 'artsy' to
appeal to (what? I have no idea), it's just a plain, simple, boring,
underwhelming, IGNORABLE interface.  You get on with your work, because you
don't have to think about the interface!

As far as changing interface elements: tools like QuickChange allow users
to affect interface elements at their leisure.  I use 3D buttons, check
boxes, and radio buttons.  What annoys me is those apps that bypass
the Toolbox calls to use these things - or use different background or
foreground colors, such that my (new) controls contrast sharply with
whatever's in the menus.  I can just imagine how confusing 6 more button
types and 6 more window types will be, especially with the 3 more that
I (an end user) add myself.

Apple, catch a clue.  Please.


Best Premises,                                      [e-mail]
Andrew R. Southwick                                 [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Fri, 19 Aug 1994 10:23:50 -0800
Organization: Integer Poet Software

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:

> Consistancy and the route of least suprise are _very_ important principles
> and I wish that stupid columnists would quit harping about the "tired old
> Mac interface".  An interface _should_ be "boring" and "underwhelming".
> It should not overwhelm the functionality of the system.  It should be
> as invisible as possible.  Since computer interfaces are definately not
> intuative, only through consistancy will we even approach the goal of
> invisibility.

I don't know about your experience, but in mine I have found that the
columnists who say this are usually Intel columnists. By that I don't mean
they work for Intel directly, but that they write about Windows or OS/2 or
perhaps even DOS. The phrase I see most is "The Macintosh interface is
showing signs of its age." The thing that's ironic about it is that the
Windows interface, a blatant copy, is basically just as old, even though
it started out radically different (and of course much much worse, but
that's a different problem). I'm not really sure what the columnists are
trying to get at, other than the fact that the Mac interface doesn't
change. That's the whole point. The Windows interface changes whenever
some jokers like Borland decide to throw in *even more* interface elements
differentiated only by color and *even more* mysterious icons decodable
only by Westerners and sometimes even only by Americans. These columnists
were weaned on DOS, where every app had a new interface. So when most
every Windows app has some new interface element for which one must read
the docs, they cope. And then they complain that the Mac interface is
"getting old" because they don't have to cope so much or so often.

It seems like one or a combination of the below things is happening.

   (1) Apple Marketing reads these columnists and figures they must know
       what they're talking about.
   (2) The market reads these columnists, figures they must know what
       they're talking about, and tells Apple Marketing, who in turn
       thinks it has no alternative but to respond.
   (3) More and more non-Macintosh engineers are getting hired at Apple
       and there's nobody left to brainwash them properly.

Frankly, from what I've seen of System 7.5, there's less and less reason
to develop for Macintosh. That ought to scare the shit out of Apple,
because the only way they'll survive is if people think there's reason to
bother.

--
 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Even during a particularly harsh (Colorado) winter... many of the
 300 families in the VCTV (movies-on-demand) trial continued to go
 to video stores." -- [e-mail], in Wired 2.09 p62

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Fri, 19 Aug 1994 10:28:35 -0800
Organization: Integer Poet Software

In article <332fsu$[e-mail]>, [e-mail] wrote:

> Why has Apple refused to develop these
> interface enhancements?  They recognize that (at least some) of them
> are needed, and Apple products use almost all of these (multiple-
> modifiers being the one exception, correct me if you've found an Apple
> product that does use them) interface methods themselves.

I don't think "refused" is quite the right word. I think what's going on
is that Apple is a disgusting fragmented byzantine re-organized
bureaucracy at this point. Nobody has the authority to put their foot down
and say "dammit, add floating window support to the Window Manager". Lots
of people can produce paperwork showing why it should wait until next year
when the Frobozzination Manager comes out. But nobody can put their foot
down.

--
 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Even during a particularly harsh (Colorado) winter... many of the
 300 families in the VCTV (movies-on-demand) trial continued to go
 to video stores." -- [e-mail], in Wired 2.09 p62

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Fri, 19 Aug 1994 10:32:17 -0800
Organization: Integer Poet Software

In article <[e-mail]>,
netcom.com!kira!davidjohn (David John Burrowes) wrote:

> But, with Microsoft coming
> out with a significantly improved user interface for Windows soon (Chicago),
> this all strikes me as Apple shooting itself in the foot...

Don't worry about Chicago's interface. Windows programmers are too
"creative" to let Microsoft get away with imposing an interface standard.
Not that Microsoft's choices would be any good. I'm more concerned that
Apple is giving eveything away by failing to internally impose standards
they worked so hard to establish.

--
 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Even during a particularly harsh (Colorado) winter... many of the
 300 families in the VCTV (movies-on-demand) trial continued to go
 to video stores." -- [e-mail], in Wired 2.09 p62

+++++++++++++++++++++++++++

>From [e-mail] (Ken Anderson)
Date: 19 Aug 94 18:05:20 GMT
Organization: (none)

>One would expect that with Don Norman in charge (he is in charge of HIG
>isn't he?) that HIG would be less worried over the "look" and more about
>the "feel".

Don Norman is an Apple Fellow and is in charge of the Personal
Digital Assistants group. The first product from that group was of
course the Newton.

The person in charge of the Human Interface group is I belive Joy Mountford,
who gave a really snazzy talk at Boston last April at CHI94.

FYI,

Ken
--
- ------------------------------------------------------------------------------
-Ken Anderson            [e-mail]                       U.C. Irvine-
- "A knowledge of C is probably better than nothing." -- J.G.P. Barnes         -
-                 Finger [e-mail] for PGP Public Key               -
- ------------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Stan Shebs)
Date: Fri, 19 Aug 1994 18:48:18 GMT
Organization: /cygint/s1/users/shebs/.organization


In article <[e-mail]> [e-mail] (Robert Mah) writes:

   I wholeheartedly concur.  Apple's HIG seems to have lost its way -- either
   that or they have lost their authority to override developer's and
   designers taste for the strange.  One would expect that with Don Norman in
   charge (he is in charge of HIG isn't he?) that HIG would be less worried
   over the "look" and more about the "feel".  That they would hire fewer
   graphic designers and more people versed in psychology and sociology.

Last I heard, Don Norman was just a researcher in ATG, and was not in
charge of any actual product work.  The only HI-related product person
I've talked to recently had just left Apple...

One of the functions of the Blue Meanies was to balance the desires of
internal developers and designers against the need for compatibility.
An Architect with real authority would do this kind of thing also.
Alas, Apple seems not to have either these days...

                            Stan Shebs
                            Cygnus Support
                            [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Rob Newberry)
Date: Fri, 19 Aug 1994 15:17:28 UNDEFINED
Organization: Education and Technology Solutions

Well, I can't tell if I agree or disagree with the others in this thread.  But
in some ways, I'm quite sure I favor enhancements to the user interface.  In
my opinion, many things in the interface need to evolve.  I am terribly
excited about the new things in System 7.5.

As I understand it, Apple is readying a new Appearance Manager, which will
let the user customize much of the interface.  I think this is a "good thing".
I'm sure it will come with a "default", but I like the idea of being able to
take control.

On the other hand, as a programmer, if I gave up on Apple already, and started
trying to implement my own 3D buttons or the like, what will happen when
Appearance Manager comes out?  Will the user be able to customize every
application (oh, yeah, by then, my app won't be an app, but an OpenDoc
"document manager") except mine?  Yikes!

In short, I wish Apple had loosened the reigns a little more earlier.  Though
I don't think they're far behind in the standard look and feel, a lot of
developers have moved on and done things that needed to be done on their own.

Rob



+++++++++++++++++++++++++++

>From [e-mail] (bgsuvax)
Date: 19 Aug 1994 19:41:27 GMT
Organization: Bowling Green State University

  Where have the standards gone?  Out the window.  But that's
been a long time coming.

  Standards are good if they are robust and evolve with change.
However the HIG standard, while at first introduction was quite
robust, didn't keep up with what was being published in the
industry.

  Take for example Word's toolbar that can be found in most of
their apps now and can also be found in other vendor's apps
(i.e. CodeWarrior).  The HIGs never evolved to encompass
toolbars, hence the thread that started here some time back
about toolbar icons representing nouns or verbs, and which
was appropriate.

  There has always been things that we, as Mac programmers,
have wanted to do but were limited by the HIGs.  So the
choice between following the guidelines or throwing the
HIGs out the window and just do what was necessary.

  While most programmers have followed the guidelines, there
are several apps out there that have had to break the HIGs
in order to do what was necessary.

  If the HIGs are dead, then RIP.  If not, then the HIG
people at Apple have some major work to do to bring the HIGs
up to snuff with respect to new interface elements and then
coerce us (the programmers) that the HIGs are worth following.

Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Fri, 19 Aug 1994 22:27:27 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
netcom.com!kira!davidjohn (David John Burrowes) wrote:

>- a strange little thing for 'post-it' notes
>- a green one for the CD player (the title bar is similar to the standard
>  document titlebar, but not the same)

These are specialized apps that don't use standard documents,
and as such are entitled to having their own user interface,
sort of. The more they go in with the Mac look, the better; and
both of these can have the window colors set to white.

>- the Find File windows have a funky styled background

It's funky in the betas, where's its a structured noise
pattern; in the release it's just a kind of subtle weave that I
don't like half as much. I pasted back the gray pattern from
the betas :-)

That pattern is available from the system file (ID=42) for
anyone who wants a gray background, presumably.

>- A window that is reminiscent of the 'palette' titlebar, but with close
>  and zoom boxes.

Yeah, but that's the new floating window WDEF that Apple wants
ALL of us to use; i e it's a STANDARD as opposed to all the
variants of floating palettes we've seen now.

However, I have this feeling people are not going to use this
floating WDEF, since the title bar is too bloody large for most
floating pallette uses - Apple says that's to make it easier to
hit for newbies, but to me, that seems less important than real
productivity for real users...

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"TextEdit does everything right."
    ã Jon W{tte


+++++++++++++++++++++++++++

>From [e-mail] (Sanford H. Selznick)
Date: 19 Aug 1994 17:58:35 -0700
Organization: University of Arizona CS Department, Tucson AZ

Why did Apple change it's UI so drastically in 7.5?  Marketing.  When
Joe computer buyer walks into a Sears or BizMart he's going to see two
computers.  He'll see a 486 box running windows 3.1 and a Mac running
system 7.1.

The 486 will undoubtedly have the calculator open.  And, well, at
first glance it looks darned good.  It's got that electric grey
background, 3D buttons, and it's big.  Is this something you'd want to
use every day?  No way.

The Mac will undoubtedly have the trash window open.  The trash icon will be
sitting in the middle of the screen.  So the sales rep says "the mac
has a calculator too."  And what does it look like?  A small blue
piece of crap that obviously hasn't evolved as fast as the windows
calculator.  It just doesn't look as good.

Before I go on, let me say I've been 1000% more productive on my mac
than I have been on a 486 box running windows.  I like the mac
calculator better too.  But when it comes time to sell a machine to
Joe Shmo, he wants to see that electric grey calculator.

Of course the graphic calculator that comes with the PPC blows
everything else away... and that's a step in the right direction.  Not
funky post-its.

IMHO,
  Sanford

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Fri, 19 Aug 1994 19:43:47 -0800
Organization: Integer Poet Software

In article <[e-mail]>, [e-mail] (Rob Newberry) wrote:

> As I understand it, Apple is readying a new Appearance Manager, which will
> let the user customize much of the interface.  I think this is a "good
thing".
> I'm sure it will come with a "default", but I like the idea of being able to
> take control.

This is a Really Bad Thing, IMO. Sure, Windows has it. So what? Windows
has a SYSTEM.INI, too. Suddenly you're going to have every half-baked
ResEdit jockey creating new Appearances, and co-workers are going to be
confused by each other's machines. It's only a matter of time before the
Control Panel interface is replaced by a text file, I guess.

> Though I don't think (Apple is) far behind in the standard look and feel...

Apple *is* the standard look and feel. It's the other vendors who've gone
off into the weeds. Some (collective) genius at Apple now thinks it's a
good idea to follow them there.

--
 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Even during a particularly harsh (Colorado) winter... many of the
 300 families in the VCTV (movies-on-demand) trial continued to go
 to video stores." -- [e-mail], in Wired 2.09 p62

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Fri, 19 Aug 1994 19:49:00 -0800
Organization: Integer Poet Software

In article <3331t7$[e-mail]>, [e-mail] (bgsuvax) wrote:

> ...the HIG standard, while at first introduction was quite
> robust, didn't keep up with what was being published in the
> industry. Take for example Word's toolbar ...

My God, the day has come to kill myself. Someone is seriously referring to
a Microsoft product as having a good interface.

To be a little less histionic, the ToolBar(tm) is the worst thing to
happen to interface in a long time, IMO. It's all well and good to have
clickable icons represent metaphorical paint tools, but when it comes to
down to saving a file, there's no good icon. But Microsoft didn't let a
little detail like *that* stop them. After all, 30 people at Microsoft
thought it was a good idea -- who else counts?

> While most programmers have followed the guidelines, there
> are several apps out there that have had to break the HIGs
> in order to do what was necessary.

Examples being?

--
 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Even during a particularly harsh (Colorado) winter... many of the
 300 families in the VCTV (movies-on-demand) trial continued to go
 to video stores." -- [e-mail], in Wired 2.09 p62

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Fri, 19 Aug 1994 21:25:17 -0800
Organization: Integer Poet Software

In article <[e-mail]>, [e-mail]
(Pete Gontier) wrote:

> To be a little less histionic

Don'tcha just hate it when you use a 50 cent word and typo it?

--
 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Even during a particularly harsh (Colorado) winter... many of the
 300 families in the VCTV (movies-on-demand) trial continued to go
 to video stores." -- [e-mail], in Wired 2.09 p62

+++++++++++++++++++++++++++

>From [e-mail]
Date: 19 Aug 94 21:57:03 MST
Organization: (none)

In article <[e-mail]>, netcom.com!kira!davidjohn (David John Burrowes) writes:
> I was reading the article about System 7.5 in the September 1994 issue of
> MacUser (p. 79-84), and it raised a gigantic question in my mind.  After
> some thought, I decided to see what opinions others (yourselves) might have.
>
> The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several
> new features of this system software release.  In them, I noted five new
> window styles:

[examples of inconsistant interface and ruminations on the subject snipt]

> If you've read this far, I'm curious what your thoughts are, either through
> personal email or on the newsgroup.  Maybe I'm very much in the minority,
> and folks generally think the 'highly consistent' interface was too
> constraining?

I think that it is obvious that 7.5 is a rush-job. Aside from AppleScript,
AOCE, GX nad one or two other exceptions, the new stuff in 7.5 all appears to
be licensed from 3rd parties and included as is without any attempt to make it
more System 7-ish.

It ain't that impressive from an HI or integrated-design standpoint, but it
DOES add needed functionality.


Maybe the 7.8 upgrade will address these issues?


Lawson

+++++++++++++++++++++++++++

>From [e-mail]
Date: Fri, 19 Aug 1994 13:58:07 GMT
Organization: Loughborough University, UK.

In article <[e-mail]> [e-mail] (Peter Castine) writes:
>In article <[e-mail]>,
>netcom.com!kira!davidjohn (David John Burrowes) wrote:
>
>> I was reading the article about System 7.5 in the September 1994 issue of
>> MacUser (p. 79-84), and it raised a gigantic question in my mind.  After
>> some thought, I decided to see what opinions others (yourselves) might have.
>>
>> The 'screenshots' on pages 80-81 and 82-83 of the above issue shows several
>> new features of this system software release.  In them, I noted five new
>> window styles:
>
>[schnipp...]
>
>> If you've read this far, I'm curious what your thoughts are, either through
>> personal email or on the newsgroup.  Maybe I'm very much in the minority,
>> and folks generally think the 'highly consistent' interface was too
>> constraining?
>
The new mini-window bar is generally considered ugly, and generated a lot
of discussion in csmp.

[..]
>It seems to me that standards are going out the window, and that this is a
>negative development. Conventional buttons and WDEFs may seem a little
>unadventurous, but in day-to-day work the security of knowing how to
>recognize a button and where the window title is are a great advantage. I
>always disliked HyperCard's anything-can-be-a-button attitude, because it
>leaves you with the challenge of clicking on *everything*, just to see if
>maybe that little chicklet-shaped object triggers some sort of action.
>This is fine and dandy for an adventure game, but frustrating when you're
>trying to get on with your work.
>
>As one example, I was looking at the new(ish) AppleCD Audio Player. The
>only reason I even tried clicking on the little green triangle in the
>lower left corner was because I knew that the fore-runner software had a
>track list and I was sure that the newer software _must_ have a track list
>somewhere. I looked in the menus, to no avail, so I started clicking
>around and the mouse finally landed on said triangle. Voila! Success at
>last!
>
>But, why the hell should I spend my time clicking around a window to find
>a substitute for the Zoom box? (Use of the zoom box as a sort of
>{show|hide}-details-of-a-dialog-window is not officially sanctioned, but
>has found it's way into a number of utility programs). Sure, if I'd turned
>on Balloon Help, I might have found this button sooner, but an experienced
>Mac user shouldn't need Balloon Help to find an _Ersatz_ zoom box.
>
I think of these as 'Easter Eggs', which I dislike. If a tool surprises me
(and a computer is a tool) then it's not transparent to me, which means
it's badly designed.

>That said, let me add that it *is* important for UIs to develop; I'm not
>going to advocate cast-in-platinum Human Interface Guidelines. The
>_Macintosh Humand Interface Guidelines_ discuss the subject of ``Going
>Beyond the Guidelines'' quite specifically.
>
>The problem with System 7.5 seems to be that Apple has simply integrated a
>couple of 3rd party extensions where graphic design went out of control,
>and nobody bothered to talk with Human Interface about what was good, bad,
>or useful.
>
Didn't Apple sack most of Human Interface a while back, on the grounds that
they needed the redundancies and human-interface people don't generate money?

[The number of applications rolling in different 3D buttons is annoying. I
don't like 3D buttons; I want consistent 2D buttons, not 3D buttons that
differ in every application.]

Quick question - how many human-interface people have ever worked for
Microsoft?

This bothers me, a lot.

L.

--

_____________________________________________________________________________
[e-mail]     Email me for a copy of the Mac screensaver FAQ


+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Sat, 20 Aug 1994 00:46:27 -0700
Organization: Infinity Systems

This discussion has brought up a lot of good points about the Bad Things
that are happening to the interface, particularly with System 7.5.

One point I'd like to make is that most of the things we're talking about
here aren't things that Apple _had_ to invent from scratch because there
weren't already prefectly good ways of doing them.  One of the things that
the HI people at Apple keep saying is to not invent new interface elements
when the ones that are available will suit the purpose.  (I'll expand this
to include that one shouldn't create new appearances for essentially the
same controls, as that effectively makes them into new controls.)


Back when System 7 first came out, I was really glad that they finally did
something about the black-and-white titlebars and scrollbars in windows.
You will notice, however, that even though they added color and 3D
effects, they did so in a tasteful manner (IMHO).

This new look was what inspired me to write the Infinity Windoid WDEF, as
the old black-and-white WDEF of the past were just lacking something.
When I first made it, however, I tried first and foremost to stay true to
the original design of floater WDEFs.  The size and position of the
gadgets were the same, and the coloring scheme matched that of the new
System 7 windows.  Although the height of the titlebar has grown 2 pixels
since this first version, I think it is still true to the earlier WDEF,
and I think that makes it easy for people to identify as a floater.

When I see the new Apple 7.5 titlebar, I instantly think 'Help Window',
because this is where it is seen most often.  Maybe this will change if
apps start using it for floaters, but I'm not sure.


As for the comments about the design of the new AppleCD Audio Player, I
don't find that as offensive as some of the other people who've commented
on it.  The main reason I feel this way is that this is what I'll call a
'consumer interface' program (it's designed to look more like a 'real' CD
Player's control panel).  My main gripe is the triangle control.  Apple
has the 'turn knob' control like is used in the old Alarm Clock DA that
would has served the purpose without adding yet another new interface
element.  (But [sarcastic tone], of course that doesn't have any color in
it...)

The new application to control the 630's TV Tuner, if you look at it, has
an interface that is similar, as it is also a consumer-type controller.

Now, we have the post-it note application.  The reason for the window
design there is that the titlebar and grow box are attempting to stay out
of the way as much as possible, so that it looks like a post-it, even when
the titlebar is active.  I may not love the fact that the interface is
different, but I at least understand it, and since I never use it
anyway...

I'm not saying these changes are all good, by any means, but _some_ of
them are understandable (if they are kept in check).

As for the Find File application window, all I can say is that Apple has
given guidelines for a 3D beveled interface in a past issue of Develop
(where a 'flat' light gray is used as the main color).  Why couldn't they
just use this interface?  And similarly, the 3D icon-buttons described in
that article would work for the buttons in the help window (without the
edges being quite so thick, as they were at least in the beta).  Though, I
didn't like the alternate push buttons, radio buttons, and check boxes
given in that article.  Use the standard CDEF, darn it!...  If people want
gray standard buttons, they can install something like Greg's Buttons and
at least have it done consistently.

Oh, and don't forget that the AppleScript Script Editor and the PowerTalk
mailer, which both use something like the Develop-described beveled
interface, even seem to use different shades of gray for the main part of
the window(!).  I could go on, but I think I'm preaching to the choir
here.

Anyway, I'd like to hear from some of the Apple people who are on the list
as to how this stuff goes on.  How do these designs get into products?  I
understand that there was one person in particular who did most of the
designs for the color icons when System 7 was released, why isn't there a
similar person who could enforce some amount of user interface
consistency?

_troy
//////// //////___Troy [e-mail]___//
  //    //      Infinity Systems                                  //
 //    //  //  Redmond, Washington                               //
//    //////____________________________________________________//

+++++++++++++++++++++++++++

>From [e-mail] (Laurent Gasser)
Date: 20 Aug 1994 12:50:33 GMT
Organization: Ecole Polytechnique Federale de Lausanne

The Human Interface Guideline specifically ban the window toolbar as
too numerous icons.  (It is in the scroll bar chapter, if my memory
is faithfull.  They show two windows, one with one or two additional
functionality to scroll bar, the other, bad example looks like Word's
windows.)  The spirit of Mac interface is quite stringent.  Remember
the guidelines about the use of color?  Don't use it as the single
way to convey information except when it is the whole information.

Basically, make the interface look simple, so simple it looks dumb.

Don't even do that: make it look sober!

In article <3331t7$[e-mail]>, [e-mail] (bgsuvax) writes:
[edited]
|>   Standards are good if they are robust and evolve with change.
|> However the HIG standard, while at first introduction was quite
|> robust, didn't keep up with what was being published in the
|> industry.
|>
|>   Take for example Word's toolbar that can be found in most of
|> their apps now and can also be found in other vendor's apps
|> (i.e. CodeWarrior).  The HIGs never evolved to encompass
|> toolbars, hence the thread that started here some time back
|> about toolbar icons representing nouns or verbs, and which
|> was appropriate.
|>
[edited]
|> Dave
|>
|> ============================================================
|> Dave Nebinger                    [e-mail]
|> Network Manager, Biology Dept.   [e-mail]
|> Bowling Green State University   dnebing@bgsuopie (bitnet)
|> Bowling Green, OH 43403          #include <std_disclaimer.h>
|>
|>              *THE* alt.sources.mac supporter!

--
Laurent Gasser ([e-mail])
Computers do not solve problems, they execute solutions.

I know very few ideas worth dying for, none is worth killing.

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sat, 20 Aug 1994 09:09:14 -0500
Organization: One Step Beyond

[e-mail] (Pete Gontier) wrote:

) [e-mail] (Robert Mah) wrote:
)
) > Consistancy and the route of least suprise are _very_ important
) > principles and I wish that stupid columnists would quit harping
) > about the "tired old Mac interface".  An interface _should_ be
) > ...
)
) I don't know about your experience, but in mine I have found that the
) columnists who say this are usually Intel columnists. By that I don't
) mean they work for Intel directly, but that they write about Windows
) or OS/2 or perhaps even DOS. The phrase I see most is "The Macintosh

Umm, well I have seen the Mac rags talk about this, but whatever, my
statement was a low blow and most journalists didn't deserve it.  Even
if they _do_ say, what I attributed to them, that certainly doesn't mak
them "stupid".   I appologize to any who may be listening in.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sat, 20 Aug 1994 09:26:38 -0500
Organization: One Step Beyond

[e-mail] (Rob Newberry) wrote:

) But in some ways, I'm quite sure I favor enhancements to the user
) interface.  In my opinion, many things in the interface need to evolve.

Just like steering wheels and typewriters, huh?  Seriouslly, techies have
a love of the new and always want change.  Change, for no good reason,
however, is anethma to a good human interface.  Again, the goals are
invisibility and no supprise.  Obviouslly, these cannot be reached, but
we can try to get closer by maintaining consistancy.

When research shows, conclusively that some interface element is out of
whack and needs change, then I'm all for it.  However, the change should
be made with respect to the existing system.

For example, Apple folk have said that research showed that normal float-
ing window move bars were too small.  OK, fine, we should make them bigger.
BUT, there is already a de-facto standard for their look (i.e. 50% gray
lines seperated by 1 pixel of background).  Why diverge from it?  There is
NO sound human interface or technical reason.


) As I understand it, Apple is readying a new Appearance Manager, which
) will let the user customize much of the interface.  I think this is a
) "good thing".  I'm sure it will come with a "default", but I like the
) idea of being able to take control.

Control is fine.  Customization is fine.  But ONLY after one has mastered
the basics.  And by rolling such a feature into the basic OS, as someone
else mentioned, one assures that inexperienced users will change the look
of their machines.

This is not good.  They will only get confused when they have to use some-
one else's machine.  They will call tech support lines and complain that
the pictures in the manual don't match what they see on their computer.
In general, the interface will become an obstical instead of an aid.


) In short, I wish Apple had loosened the reigns a little more earlier.
) Though I don't think they're far behind in the standard look and feel,
) a lot of developers have moved on and done things that needed to be
) done on their own.

But that's _part_ of the "official" guidelines.  If there is no accept-
able standard interface element that fits, create something new that
does.  Just make sure you consider the standard and de-facto standard
elements first.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sat, 20 Aug 1994 09:36:11 -0500
Organization: One Step Beyond

[e-mail] (Jon W{tte) wrote:

) netcom.com!kira!davidjohn (David John Burrowes) wrote:
)
) >- a strange little thing for 'post-it' notes
) >- a green one for the CD player (the title bar is similar to the standard
) >  document titlebar, but not the same)
)
) These are specialized apps that don't use standard documents,
) and as such are entitled to having their own user interface,
) sort of. The more they go in with the Mac look, the better; and
) both of these can have the window colors set to white.

I disagree.  The CD-Player controls an external device with a small
number of discrete controls.  While its similarity to "real world"
CD players could be argued, I must point out that _my_ real CD player
looks nothing at all like the software CD-Player.  Actually, now
that I think about it, very few real CD-players look like that
program's main window.

As for the Post-It (r) notes software.   Give me a break.  It's just a
bunch of windows for jotting quick notes that remember their locations.
I'm not denigrating the app, it's quite nicely done, but really...user
selectable color backgrounds would have been OK, but no standard (or
even miniature) grow box, etc., etc.  There's no excuse except ego
gratification.


) Yeah, but that's the new floating window WDEF that Apple wants ALL of
) us to use; i e it's a STANDARD as opposed to all the variants of float-
) ing palettes we've seen now.

What "varients" ?.  Except for a few apps that use the standard WDEF for
their floaters, they all look very similar (other than the use of color).
Only Apple's looks different.  They are the varient, the one at odds with
the de-facto standard that has emerged over the last few years.

If Apple had simply bought Troy's Infinity Windoid, everyone would have
been better off.  Especially the users (even if they wouldn't know it).

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sat, 20 Aug 1994 09:54:50 -0500
Organization: One Step Beyond

[e-mail] (bgsuvax) wrote:

) Standards are good if they are robust and evolve with change.  However
) the HIG standard, while at first introduction was quite robust, didn't
) keep up with what was being published in the industry.

This is an irrelavent argument.  There is no "human interface" industry
to keep up with (though I understand you meant the computer or software
industry).  And I would argue that keeping up with the Joneses is not
a worthy goal.

Human interface design should pay more attention to new perspectives in
the fields of psycology, sociology, cognition, perception, linguistics,
learning theory, etc. than the computer and software field.  These "soft"
fields are much more important, because the purpose of human interface
design is to mold the machine (or software) the person.  A better under-
standing of human behaviour will lead to better designs.


) Take for example Word's toolbar that can be found in most of their apps
) now and can also be found in other vendor's apps (i.e. CodeWarrior).
) The HIGs never evolved to encompass toolbars, hence the thread that
) started here some time back about toolbar icons representing nouns or
) verbs, and which was appropriate.

The previous discussion to which you refer was more about whether one
should mix nouns, verbs and adjectives/adverbs in palettes.

Microsoft made the cardinal sin of not considering the underlying rational
for tool palettes (e.g. in paint programs).  They never stopped to examine
just what was being presented to the user and why tool palettes were a
valuable addition to the user interface.

Instead, they said (or so I surmise)...

  "Let's add icons -- icons are cool."
  "But what icons?  We don't have any tools like paint bucket in Word..."
  "How about something for the basic commands like print and save?"
  "Yeah, that's it!"
  "OK, how 'bout a spell checker icon?"
  "Cool man."
  ...
  ...
  "Uh, Joe, what does that icon mean?"
  "Oh, that's the 'Paste special' icon, can't you tell?"
  "Well, no...I guess we should add some help"
  "Great idea!  That way, no one will get confused because we'll have
   text explaining what each icon does!"
  "Cool man."

My question: if you need text to explain a large percentage of the icons,
then why use the silly icons in the first place?

The REASON why the toolbars in word and excel (and other programs) are
undeciferable by modern man are twofold.

1. They depart from the normal practice of using icons to represent nouns.
   That is _things_ that can be manipulated.

2. Each application has it's own "vocabulary", leading to a Tower of Babel.
   Users must learn a new and different "iconic language" for each app.
   This is obviouslly not a good thing.

If there were a standardized vocabulary AND verb-icons could be visually
distinguished from noun-icons and modifier-icons (i.e. adjectives and
adverbs) then, and only then, will toolbars become a truely useful interface
element.

Note that, on the Mac anyway, there is already a standardized vocuabulary
for many graphics app-oriented tool icons.  Color seed fill tools are paint
buckets.  Color grabbers are little eye droppers.  Pencils draw points and
free form lines that follow the cursor.  This standardized vocabulary
allows these tools to become "invisble" once they learn them.  Learn them
once.

This goes back to more subtle things like the Apple's own special look for
floating windows.  Now people have to recognize TWO types of windows as
floaters.  This is not good.

Phew!  Enough typing for now.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (bgsuvax)
Date: 20 Aug 1994 18:15:31 GMT
Organization: Bowling Green State University

  Whew, mention Word's toolbars and I end up catching some flames! ;-)

  Anyway, all points mentioned about Word's toolbars don't have much
thought behind them are true.  I never meant to say that Word's interface
was the best and we should all turn towards Washington and say "We're
not worthy!"

  I did want to show how graphical elements like Word's toolbar have
been popping up and there is nothing in the HIGs to govern their appearance
nor what they should contain (nouns, verbs, adjectives/adverbs).  Other
items have been world floating windows, system menus, etc.  There are
lots of examples of things that have been done which aren't covered in
the HIGs.  Do the HIGs say anything about removing the Help menu like
SpeedyFinder does, etc.

  As far as Word's toolbar goes, I like it.  I like the fact that I
can set up my own tool to represent a command which I might use from
time to time that I forget what the key combination is (is that cmd-opt-u
or cmd-opt-cntrl-u or cmd-opt-shift-u ...).

  Other apps have been adding toolbars, too.  OmniPage 5.0 has one,
most MS products have one, I understand that CodeWarrior has one too.
Toolbars are showing up all over the place, but the HIGs don't say
whether nouns, verbs, or adj/advs should be used.

  My whole point was that the HIGs have to be constantly evolving to
cover new things like toolbars, etc.  You can't just set up some standards
and expect them to stay golden forever without change.

  Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 20 Aug 1994 18:21:56 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:

> The REASON why the toolbars in word and excel (and other programs) are
> undeciferable by modern man are twofold.
>
> 1. They depart from the normal practice of using icons to represent nouns.
>    That is _things_ that can be manipulated.
>
> 2. Each application has it's own "vocabulary", leading to a Tower of Babel.
>    Users must learn a new and different "iconic language" for each app.
>    This is obviouslly not a good thing.
>
> If there were a standardized vocabulary AND verb-icons could be visually
> distinguished from noun-icons and modifier-icons (i.e. adjectives and
> adverbs) then, and only then, will toolbars become a truely useful interface
> element.
>
> Note that, on the Mac anyway, there is already a standardized vocuabulary
> for many graphics app-oriented tool icons.  Color seed fill tools are paint
> buckets.  Color grabbers are little eye droppers.  Pencils draw points and
> free form lines that follow the cursor.  This standardized vocabulary
> allows these tools to become "invisble" once they learn them.  Learn them
> once.
>
> Phew!  Enough typing for now.
>
> Cheers,
> Rob
> _____________________________________________________________________
> Robert S. Mah           Software Development          +1.212.947.6507
> One Step Beyond        and Network Consulting          [e-mail]


Let me add a bit of grist to this mill.  It is simply not true that icons
on the Mac are always used as nouns.  This is true in the Finder where
icons represent files, and in Resedit.  The icon buttons used in graphics
programs indicate something like 'change the cursor to a pencil tool' or
'change the cursor to the paint bucket tool'.  Icon buttons are a hybrid
between icons and buttons.  All buttons act as verbs, including icon
buttons.  I don't think there is ever a confusion between icons-as-nouns
and icons-as-verbs.  The drop shadow

One could argue that the calculater DA uses a primitive icon-button
interface.  The '*' and '/' and '+' keys use symbols to indicate their
functions.  These buttons are also not standard Mac pushbuttons.  This
interface works because it's so similar to real calculaters that there is
little or no learning curve.

Hypercard uses '->' buttons to indicate 'go to the next card'.

The old Font/DA mover had a standard pushbutton with '>>' on it to
transfer fonts from the left list box to the right list box.  Admittedly
that interface wasn't God's gift to interfaces but it is a case where a
symbol, rather than words was used on a button.  That interface lives on
in lots of places, like 'Add Files' dialog boxes, although often there is
a word rather than a symbol.  Presumably we'll be seeing drag-and-drop
replacements for this RSN ;).

The problem with icon buttons is that it's often hard to remember what
they represent and there are often too damn many of them.  FWIW I never
use Word's toolbar.  (Also Word's toolbar takes a loooong time to
redraw.)  In Word's defense the toolbar can be turned off, and anything
that you can do with the toolbar can also be done with the menus, and in
many cases with command key equivalents.

The icons on icon buttons are simply meant to replace the words that would
go there.  And this is done to save space on the buttons, and to be cool,
of course.  I think that the key to good icon buttons is to have not very
many of them.  That allows you to remember what they do.

--
Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sat, 20 Aug 1994 20:42:57 -0500
Organization: One Step Beyond

[e-mail] (Brian Stern) wrote:

) Let me add a bit of grist to this mill.  It is simply not true that icons
) on the Mac are always used as nouns.  This is true in the Finder where
) icons represent files, and in Resedit.  The icon buttons used in graphics
) programs indicate something like 'change the cursor to a pencil tool' or
) 'change the cursor to the paint bucket tool'.  Icon buttons are a hybrid
) between icons and buttons.  All buttons act as verbs, including icon
) buttons.  I don't think there is ever a confusion between icons-as-nouns
) and icons-as-verbs.  The drop shadow

To you, the programmer, the pencil icon may mean, "change internal mode to
kPencilToolMode", but to the user it means, "I wanna use the pencil now".
That is, the icon is a graphical representation of a tool, a thing.  That
this "thing" doesn't actually exist is not relavent.  I.e. when I talk
about nouns-vs-verbs, I'm looking at the icons from the user's viewpoint.

Icon buttons, without text are, IMO, not good, because they try to represent
actions as icons.  Same problem as MS-style toolbars.



) One could argue that the calculater DA uses a primitive icon-button
) interface.  The '*' and '/' and '+' keys use symbols to indicate their
) functions.  These buttons are also not standard Mac pushbuttons.  This
) interface works because it's so similar to real calculaters that there
) is little or no learning curve.

Software calculator interfaces work because of three reasons...

1. As you mention, there are real world analogues to the user interface.

2. The buttons represent well known concepts (the digits, adding etc.)

3. The graphical representation of these concepts have been standardized.
   I.e. there is a common and accepted vocabulary.  "+" means add.  "="
   means equals.  Etc.

Thus, as you say, there is no confusion.  However, imagine what would
happen if you added a "save paper tape to file" button to the caculator

Note that, in this specific case, the criteria that I set forth for the
use of icons to represent verbs have been fullfiled.  Thus, it works.
Most applications and software in general do not fullfil these criteria.


) Hypercard uses '->' buttons to indicate 'go to the next card'.

Don't even get me started on HyperCard!  No thought seemed to have been
given to interface design on that thing.  Problems like floating palettes
that de-hilite, fixed window sizes, dynamically changing menus, too many
modes, modal editors, etc.  Many problems were fixed in later versions
and the current one is actually starting to get decent.


) The old Font/DA mover had a standard pushbutton with '>>' on it to
) transfer fonts from the left list box to the right list box.  Admittedly
) that interface wasn't God's gift to interfaces but it is a case where a
) symbol, rather than words was used on a button.  That interface lives on
) in lots of places, like 'Add Files' dialog boxes, although often there is
) a word rather than a symbol.  Presumably we'll be seeing drag-and-drop
) replacements for this RSN ;).

Ever remember seeing someone try to figure out Font/DA Mover?  The concept
is simple to those who understand the mechanics, but to normal users who
don't want to understand resources and such, it was a royal nightmare.

Wouldn't it have been better to title the buttons as "Move ->" or even
better "Move To File XYZ".  Or even better, drop the damn thing and move
its functionality to the Finder where people don't have to learn yet
another method of moving objects around.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: 21 Aug 1994 01:37:23 GMT
Organization: The Information Workshop


When I explain what is heappening in the world of computers to
non-computer people, I like to draw an analogy to the early days of
automobiles, when between the different manufacturers, there were
different ways to steer, and different ways to start, stop, and make the
horseless-carriage go.

Maybe that analogy is useful in this discussion.

Today, we can get into a 1965 Galaxie 500, or a 1994 Supra, and easily
know what to do to drive either of them.

Perhaps we are at the stage where we can be a little loose, and allow for
some differing styles on our screens.

As long as the close box, zoom box, grow box, and drag bar are clearly
obvious and work the expected ways, a window is a window.

The same with buttons.

Maybe this is the beginning of wriggling out of the super-restricted
user-interface thinking we have been in for so long.

At first it was "the march to enforce consistency", and the Macintosh made
its point.  Now that we have done that, and everyone understands the
fundamental value of consistency, we can let up and allow some style.

You know those telephones with the gigantic numbers on buttons that are 2
inches on a side?....

:)

Mark Hanrek
The Information Workshop

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sun, 21 Aug 1994 02:21:21 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Sanford H. Selznick) writes:
>Of course the graphic calculator that comes with the PPC blows
>everything else away... and that's a step in the right direction.  Not
>funky post-its.

      Agreed.  With the PowerMac, application developers are guaranteed
a certain floor of performance, which makes possible apps that depend
on that floor.  Graphic Calculator is an example; something like that
is too unwieldy to use if it updates slowly.  3D editing programs can
be written to assume the model can be manipulated interactively.
Look at Ashlar Vellum for something that intelligently uses CPU
time in an interactive way.

      This is the way to a "killer app" that sells PowerMacs to PC
users.  Unless Apple comes up with something that moves users from
PCs to Macs, Apple's market share will steadily decrease, because users
are already moving the other way.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Sun, 21 Aug 1994 02:49:17 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
David John Burrowes <netcom.com!kira!davidjohn> wrote:
>If you've read this far, I'm curious what your thoughts are, either through
>personal email or on the newsgroup.  Maybe I'm very much in the minority,
>and folks generally think the 'highly consistent' interface was too
>constraining?

Others must have noticed that Apple, Microsoft, and any plethora of
other GUI builders are doing what they've always been doing. Stealing
(uh, adapting) ideas from eachother. Apple anounces a new feature,
Microsoft isn't far behind. Microsoft announces a new feature, Apple
isn't far behind (my favorite example of this is preemptive
multitasking and threads). What you're seeing is Apple doing what it
has always done, and will continue to do. Their documentation as to
"standards" is temporary gibberish; there are so many standards of
such short life-spans, that the term "standard" in computer-world has
little meaning. In the end, I don't think users really care if their
buttons are 3-D shadowed, or if they're rounded, square, or whatever.
They just want software that's useful or fun, or that, at a minimum,
marketing can convince them to buy. It doesn't really matter if it's a
mac, a windows, a car, a dog, or a cat. People are people are people,
and will always behave as people. Oh gosh, I'm straying. Let me get
off of my soap box.

Ah, that's better. Cheers!
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Sun, 21 Aug 1994 03:10:46 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Pete Gontier <[e-mail]> wrote:
>Frankly, from what I've seen of System 7.5, there's less and less reason
>to develop for Macintosh. That ought to scare the shit out of Apple,
>because the only way they'll survive is if people think there's reason to
>bother.

For me, it's not 7.5. It's the pathetic state of the APIs and
documentation. Who wants to spend their life looking through 16000
pages? There is no reason the OS needs to be that complicated. And no,
a legacy OS is not a reason for rampant complexity. And OpenDoc is
only going to make it worse. Oh ya, and six (SIX!!!) books for QDGX.
Geesh. Unfortunately for the world, Microsoft is making the exact same
mistakes. Oh well.

And then, there are the development tools. We all know what sorry
state they've been in and continue to be in. And the pathetic
languages used for development (this isn't a mac-only problem; none of
this is a mac-only problem).

Finally, there's the market share. Many more windows machines than
macs. Solution? Some cross-platform package. Well, then you get into
deciding which one to use, will the company be around, convincing your
engineers, etc.

Why do I do mac development? Because I learned it years ago and manage
to keep up with a minimum of the dumb system junk they produce. And I
can still get work doing it, because there are several million macs
out there, and that's a reasonably sized market. And because learning
another OS is a major hastle (see above). And it pays my bills so I
can do what I want to do. And no, that's not program computers all the
time. Really. No, really.

Here's my schpiel: computers suck. They all suck. But they're useful
tools for certain problems. But give me 50 years, maybe 100, and no
one will talk of digital computers. It will be about systems that
immitate biological systems. We all run around with the most powerful
information processing system on our shoulders. It's the ultimate in
portability. Well, obviously we don't do matrix multiplications too
fast, but that's about all computers beat us at. Yes, biology is the
future. Even a single living cell (even a bacterium!) puts computers
to shame. Small, efficient, fast, robust (!!), disposable, recyclable.
Engineering on the atomic level. People who talk about nano-machines
don't know squat about the future. An enzyme is a nano-machine, built
atom by atom, in a process no one can describe fully. And you've got
so many trillions of them, constantly being built and destroyed, of
such an incredible variety. Really, computers do suck. And yes,
they're useful tools. Heck, they pay the food bills, so this
biological entity can continue to pontificate and study itself :-)

--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Sun, 21 Aug 1994 03:19:49 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Pete Gontier <[e-mail]> wrote:
>I don't think "refused" is quite the right word. I think what's going on
>is that Apple is a disgusting fragmented byzantine re-organized
>bureaucracy at this point. Nobody has the authority to put their foot down
>and say "dammit, add floating window support to the Window Manager". Lots
>of people can produce paperwork showing why it should wait until next year
>when the Frobozzination Manager comes out. But nobody can put their foot
>down.

I put my foot down. Oh, but it doesn't seem to have done any good :-)

Too bad the only PC company to come along in the last 10 years to
offer something useful died (well, sort of, it's not dead yet). NeXT
of course. We could all have been 5 years ahead of the game had NeXT
pinned Apple and MS against the ropes.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Sun, 21 Aug 1994 03:26:00 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Jon W{tte <[e-mail]> wrote:
>However, I have this feeling people are not going to use this
>floating WDEF, since the title bar is too bloody large for most
>floating pallette uses - Apple says that's to make it easier to
>hit for newbies, but to me, that seems less important than real
>productivity for real users...

Why couldn't they just have bought Troy's cool Windoid (or done their
own, if they disliked the idea of anyone ever knowing that Apple ever
had anything to do with something that was, gasp, free with source
code) and added a "Windows" control panel that let users set the
height of stupid title bar? Users who need BIG title bars could click
the BIG TITLE BAR button, and users who need tiny title bars could
click the tiny title bar button, and super expert users could enter a
measurement (in centimeters or inches, NOT pixels) into a little text
field. The modifications to the windoid to make its title bar's height
adjustable would have been miniscule, and would have made the UI
adaptable to the particular needs of individuals with minimal impact
on overall consistency.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Sun, 21 Aug 1994 03:30:46 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
 <[e-mail]> wrote:
>I think that it is obvious that 7.5 is a rush-job. Aside from AppleScript,
>AOCE, GX nad one or two other exceptions, the new stuff in 7.5 all appears to
>be licensed from 3rd parties and included as is without any attempt to make it
>more System 7-ish.

With all those 3-rd party ideas included in sys 7.5, why, oh why,
couldn't they have included drop-down menus and stick-up menus? It
would have made life so much easier on my tired hands (that have to
click, hold, and drag to access a menu command, a very very bad thing
from a human engineering POV).
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Sanford H. Selznick)
Date: 20 Aug 1994 20:21:36 -0700
Organization: University of Arizona CS Department, Tucson AZ

In article <[e-mail]>,
[poof!]
>... In the end, I don't think users really care if their
>buttons are 3-D shadowed, or if they're rounded, square, or whatever.
>They just want software that's useful or fun, or that, at a minimum,
>marketing can convince them to buy. It doesn't really matter if it's a
>mac, a windows, a car, a dog, or a cat.

So this actually brings up an important point.  Is the mac supposed to
be a computer to _buy_ or a computer to _use_?  Is there a happy
medium?

I say yes, but not when you put mail software under the special menu
and Shut Down in the Apple menu.  What percentage of macs end up on a
network anyway?  (Does it even do POP3?)  The transition from 6 to 7
added a lot of good features.  The transition from 7 to 7.5 adds too
many bells and whistles for my taste.

As I bring up yet one more point in the same breath...

When I'm not in school or working for the U, I do independent
consulting.  One thing I can always count on is macintosh consistency.
I can sit down at any mac and know my way around.  The users (once
they get good, and they do so rather quickly) see this too.  And that
too is a selling feature they they can talk about to their friends.
Different is good.  Different with efficiency is even better.

IMHO,
  Sanford


+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Sun, 21 Aug 1994 03:43:35 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Robert Mah <[e-mail]> wrote:
>Human interface design should pay more attention to new perspectives in
>the fields of psycology, sociology, cognition, perception, linguistics,
>learning theory, etc. than the computer and software field.  These "soft"
>fields are much more important, because the purpose of human interface
>design is to mold the machine (or software) the person.  A better under-
>standing of human behaviour will lead to better designs.

Ok, here's the new alert for deleting a locked file:

"While it's ok to delete a locked file, you should remember that this
does not deal with the more basic problem of why the file is locked.
Merely deleting this file will not solve your problems, which arrise
out of years of neglect and rejection.

       -----------------  --------------------   ----------------
      | Call My Shrink | | Load Caring Mother | | Please Help Me |
       ----------------   --------------------  | Understand My  |
                                                | Inner Child    |
                                                 ----------------
"

Sorry, I couldn't resist it. I do agree with Rob, though.

Boy, this thread is so much fun. I haven't posted so many stupid and
irrelevant things since, uh, oh I don't know.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sun, 21 Aug 1994 05:55:39 -0500
Organization: One Step Beyond

[e-mail] (Ari I Halberstadt) wrote:

) Ok, here's the new alert for deleting a locked file:
)
) "While it's ok to delete a locked file, you should remember that this
) does not deal with the more basic problem of why the file is locked.
) Merely deleting this file will not solve your problems, which arrise
) out of years of neglect and rejection.
)
)        -----------------  --------------------   ----------------
)       | Call My Shrink | | Load Caring Mother | | Please Help Me |
)        ----------------   --------------------  | Understand My  |
)                                                 | Inner Child    |
)                                                  ----------------

Damn that's funny!  I'm not quite sure _why_ I thought it was so funny..
..maybe it has something to do with supressed memories of my childhood..

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 21 Aug 1994 12:48:46 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:

> [e-mail] (Brian Stern) wrote:
>
> ) Let me add a bit of grist to this mill.  It is simply not true that icons
> ) on the Mac are always used as nouns.  This is true in the Finder where
> ) icons represent files, and in Resedit.  The icon buttons used in graphics
> ) programs indicate something like 'change the cursor to a pencil tool' or
> ) 'change the cursor to the paint bucket tool'.  Icon buttons are a hybrid
> ) between icons and buttons.  All buttons act as verbs, including icon
> ) buttons.  I don't think there is ever a confusion between icons-as-nouns
> ) and icons-as-verbs.  The drop shadow
>
> To you, the programmer, the pencil icon may mean, "change internal mode to
> kPencilToolMode", but to the user it means, "I wanna use the pencil now".
> That is, the icon is a graphical representation of a tool, a thing.  That
> this "thing" doesn't actually exist is not relavent.  I.e. when I talk
> about nouns-vs-verbs, I'm looking at the icons from the user's viewpoint.
>
> Icon buttons, without text are, IMO, not good, because they try to represent
> actions as icons.  Same problem as MS-style toolbars.
>
> Cheers,
> Rob
> _____________________________________________________________________
> Robert S. Mah           Software Development          +1.212.947.6507
> One Step Beyond        and Network Consulting          [e-mail]

All buttons represent verbs; if you click a button then some action
occurs.  Buttons also have some information on them to help you remember
the action associated with them.  In the traditional case this is in the
form of words, in the case at hand it is little pictures.  I agree that we
should look at this from the user's perspective.

Clicking on the pencil button does mean 'use the pencil now', and that's
an action, not a noun.  If a graphics program was to maintain the Finder's
paradigm of 'select a file and then select an action to be done to that
file', there would be a tool palette that had some number of tool icons on
it.  To change the current tool to the pencil the user would select the
pencil icon in the tool palette and then choose a menu item or hit a
standard button that said something like 'use selected tool'.  This could
work but would probably be less convenient than the icon-button approach.

The fact that these buttons have icons on them is an implementation
detail.  I think that you're seeing them from a programmer's perspective.
I doubt that many users think of these as icon-buttons.  They're merely
buttons.  I don't believe that there is any confusion between the pictures
on these buttons and the pictures that the Finder shows you.  Everyone
knows that clicking on a button does something.  The hard part is
remembering or figuring out what a particular button does.

I agree that excessive use of icon-buttons causes problems (see your
physician or clergyman for treatment:)  I don't agree that this has
anything to do with nouns or verbs.  The problem is that when you have a
whole slew of them it's very hard to remember what they all do.

One of the most important strengths of the Mac interface is the way that
it's easy to remember how things work.  When people say that the Mac
interface is intuitive what they really mean is that things are 'easy to
remember'.  Intuitive really means 'easy to figure out'.  Icon buttons are
usually not 'easy to remember' and they're often not 'easy to figure out'
either.

--
Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sun, 21 Aug 1994 14:47:56 -0500
Organization: One Step Beyond

[e-mail] (Brian Stern) wrote:
)
) All buttons represent verbs; if you click a button then some action occurs.

Yes, I'll agree with this.  However, tool palettes as commonly used in
graphics apps are not like normal buttons because they stay hilited
over time.  Normal buttons initiate an action and then return to their
unhilited state immediately (or should).

But leaving that asside for now, you raise an interesting point...


) Clicking on the pencil button does mean 'use the pencil now', and
) that's an action, not a noun.

If you point to the pencil tool icon and ask users, "what is that?"
Most usrers will not say, "that's the button that turns on the pencil
tool".  They will say, "that's the pencil tool".  That icon has taken on
the meaning of that tool.  It is a word, expressed as a heiroglyph that
represents the tool, "pencil", in the mind of the user.  In short, a noun.

Turning that around, if you ask, "what does that do?", then they may say,
"it lets me use the pencil".

The reason for this seeming dichotomy is the question itself.  The second
question was phrased in a manner that elicits a functional responce
instead of a descriptive one.

This can be easily turned around and used to "proove" that a common soft-
ware "verb" is actually a "noun".  Point to the a scroll bar in a window
and ask, "What is that?".  Which could easily lead to a responce such as,
"That's a scroll bar".  Then again, ask, "What does this do?" and you, of
course, get, "It makes the text move up and down".

It's all a matter of perspective and language.


) I agree that excessive use of icon-buttons causes problems (see your
) physician or clergyman for treatment:)  I don't agree that this has
) anything to do with nouns or verbs.  The problem is that when you have
) a whole slew of them it's very hard to remember what they all do.
) [...]
) Icon buttons are usually not 'easy to remember' and they're often not
) 'easy to figure out' either.

One point in differentiating between "noun" icons and "verb" icons is that
a standard vocabulary is much easier to build with "noun" icons.  That is
why, in fact, a small one already has.  It's easier because "nouns" are
often used to represent software-things which one can easily represent
with a picture of a similar real-world analogue.

Verbs, however, by their very nature are more ephemeral.  They are not as
easily represented by pictures, and in fact, some designers have taken to
using pictures of _things_ to represent _actions_.  E.g. printer icon
buttons to print documents.  This is NOT the same as the use of printer
icons in Quickdraw GX on the desktop.  Here, they are used to represent
things...a destination that prints documents.  So, it fits within the
overall scheme of the Finder.


So, finally, I would like to stress that it's not toolbars, per se, that
bother me, it's the gratuitous use of babbeling icons to represent actions
(i.e. verbs) without regard for standardization.

The icons used in these buttons ARE a written language.  Just as ancient
Egyptian hieroglyphics is a written language.  But a language needs a
commonly recognized vocabulary to be decipherable.  Until we have one, I
feel that it is almost always more appropriate to use the local language
of choice.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 21 Aug 1994 21:02:27 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:
[snip]
> So, finally, I would like to stress that it's not toolbars, per se, that
> bother me, it's the gratuitous use of babbeling icons to represent actions
> (i.e. verbs) without regard for standardization.
>
> The icons used in these buttons ARE a written language.  Just as ancient
> Egyptian hieroglyphics is a written language.  But a language needs a
> commonly recognized vocabulary to be decipherable.  Until we have one, I
> feel that it is almost always more appropriate to use the local language
> of choice.
>
> Cheers,
> Rob
> _____________________________________________________________________
> Robert S. Mah           Software Development          +1.212.947.6507
> One Step Beyond        and Network Consulting          [e-mail]

I think what this comes down to is problems with the replacement of text
with graphics.

Consider the icons (or pictographs) at the tops of the reply windows in
NewsWatcher and Eudora.  In these cases icons are used to replace the text
in checkboxes.  The Newswatcher one works for me because there are only
three icons.  Interestingly, the Send function is accomplished by a
standard pushbutton with text in it.  The icons in Eudora's reply window
never worked for me because I never could figure out what they all meant
and I only used the program occasionally.

Consider also the icons in alert boxes.  These can't be manipulated in any
way.  They just convey the meaning of 'Warning' or 'here's something you
should know'.  This works because there are relatively few different alert
icons.  Imagine a program with a different alert icon for each error
message.

So what we're seeing is the replacement of text with graphics in a number
of places.  I do agree that it is usually more difficult to describe a
verb with a graphic than it is to describe a noun with a graphic.  I
think, again, that the problem is one of ease of remembering and ease of
figuring out.

OTOH, what about command key equivalents.  At first blush it would seem
that pictures are better at describing actions than random letters.
However, noone complains that command key equivalents are 'bad'.  I guess
part of it is that you can always look up the meaning of a command key
equivalent by pulling down the menus, and another part is that they are
completely unobtrusive if you don't use them.

I think you're right that there needs to be some standardization [hey we
got back to the title of this thread] of icons for use in place of text.
It won't be easy though.  And tool palettes are too sexy for most
developers to think twice about not implementing them wherever they can.

--
Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Klaus)
Date: 21 Aug 1994 23:16:27 GMT
Organization: Parentheses and Ellipses

In article <[e-mail]>
[e-mail] (Troy Gaul) writes:

> As for the comments about the design of the new AppleCD Audio Player, I
> don't find that as offensive as some of the other people who've commented
> on it.  The main reason I feel this way is that this is what I'll call a
> 'consumer interface' program (it's designed to look more like a 'real' CD
> Player's control panel).

When you're playing a CD, you see a lit-up "pause" control.  When you have a
CD paused, you see a lit-up "play" control instead.  Rather unlike a 'real' CD
player, in which the lit-up control is the one that's currently active (e.g.
when you're playing a CD, the "play" control is lit up).  This violates
another principle of user interface design: If you make changes to an
interface, those changes should be obvious.  You should never have a
familiar-looking interface element perform an unexpected function.

 -Klaus ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Herb Voth)
Date: Mon, 22 Aug 1994 03:09:38 GMT
Organization: Ministry of Education

The way I see this button problem is this:

-MS basically duplicated all their menu and key combo features in buttons.
This can never be intuitive because there are too many options to
remember. Whoever decided that we needed a 'cut' button was more
interested in the gee whiz MTV factor than productivity. The fact that MS
has advertised the hell out of it, calling it productive does not make it so.

-MS changed the metaphor that was introduced with MacPaint where buttons
basically changed the context of editing a document. The buttons were more
like tools. MS decided that menus were dumb and has basically made them
redundant rather than complementing them the way MacPaint did.

-Programs are getting so feature rich that MS's metaphor of implementing
all features in buttons is a diminishing return, very short-sighted
interface. Having 15 button bars is not productive, it just sells 21"
monitors.

-People (who pay our salaries, of course) want buttons. So, we must
implement them. For them to be useful, they must be customizable. And,
*most importantly* they must be able to be hidden. As such, they must be
only one way of accessing each feature. I hate it when I have to turn on a
button bar just to access a feature.

-How about a button bar that appears when you press CTRL?

-Randall

--

+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: 22 Aug 1994 04:25:07 GMT
Organization: The Information Workshop

In article <[e-mail]>, [e-mail] (Ari I
Halberstadt) wrote:

> For me, it's not 7.5. It's the pathetic state of the APIs and
> documentation. Who wants to spend their life looking through 16000
> pages? There is no reason the OS needs to be that complicated. And no,
> a legacy OS is not a reason for rampant complexity. And OpenDoc is
> only going to make it worse. Oh ya, and six (SIX!!!) books for QDGX.
> Geesh.
>
> And then, there are the development tools. We all know what sorry
> state they've been in and continue to be in. And the pathetic
> languages used for development (this isn't a mac-only problem; none of
> this is a mac-only problem).

Ari,

I agree with your assessment 100%.

I have come to discover that one of the reasons things are this way is
because programmers aren't as demanding as they could/should be.

A majority accept things too easily, and adapt to the way things are too
easily.

Often, programmers figure that if they don't understand something, it is
their fault, and then won't say anything.

Our tools ARE pretty crummy, yet look at the amazing and sophisticated
things we create with them routinely for others.

Why don't we want tools that are equally sophisticated?  Why do we put
ourselves through building fine creations with just a screwdriver and a
hammer? :)

- ---

It reminds me of the "typical" mechanic, who can fix and tweak your car
and make it sing, but his car runs like ****.   :)

Likewise, programmers build the eWorlds, and the First Class BBSs, and
slick collaborative groupware for those how know it is a competitive
must...

... but for some reason programmers find the less-than-primitive nature of
the internet newsgroup to be "just fine" for discussing sophisticated
technologies and rearing their young.


Amazing, ain't it?

Mark Hanrek
The Information Workshop

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 22 Aug 1994 09:24:36 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

>Clicking on the pencil button does mean 'use the pencil now', and that's
>an action, not a noun.  If a graphics program was to maintain the Finder's

Now it's getting interesting.

Clicking on a pencil BUTTON would mean "use the pencil now"
which is giving a command.

However, picking up a pencil from a palette (toolbox) would be
akin to doing just that, physically, in the real world; picking
up a pencil out of a toolbox, and there the pencil tool is most
definately a noun.

These are two ways of using icons that differ subtly. I hope
that subtlety doesn't get lost in a noise of toolbars...

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
    Not speaking for the Microsoft Corporation.


+++++++++++++++++++++++++++

>From [e-mail] (Derick Siddoway)
Date: 22 Aug 1994 07:58:52 GMT
Organization: University of Utah

In article <[e-mail]>
[e-mail] (Ari I Halberstadt) writes:

> Here's my schpiel: computers suck. They all suck.

Spiel?  That's my *mantra*.

- ---------
Derick H. Siddoway                __o      If you stew cranberries like
[e-mail]            _>\<,_     applesauce, they taste much
University of Utah             (_)/ (_)    more like plums than rhubarb
Department of Electrical Engineering       does.  - (Groucho Marx) -

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 22 Aug 1994 11:25:06 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail]
(Jon W{tte) wrote:

> In article <[e-mail]>,
> [e-mail] (Brian Stern) wrote:
>
> >Clicking on the pencil button does mean 'use the pencil now', and that's
> >an action, not a noun.  If a graphics program was to maintain the Finder's
>
> Now it's getting interesting.
>
> Clicking on a pencil BUTTON would mean "use the pencil now"
> which is giving a command.
>
> However, picking up a pencil from a palette (toolbox) would be
> akin to doing just that, physically, in the real world; picking
> up a pencil out of a toolbox, and there the pencil tool is most
> definately a noun.
>
> These are two ways of using icons that differ subtly. I hope
> that subtlety doesn't get lost in a noise of toolbars...
>
> Cheers,
>
>                                 / h+
>
>
> --
>   Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
>     Not speaking for the Microsoft Corporation.

In thinking about this some more, and looking at a graphics program, I've
realized that some of these tool pallettes are actually groups of
radiobuttons.  You have a bunch of choices, from which you can only choose
one, and that selection remains hilited.  Choosing one changes the
channel, if you will.

So all three of the standard Mac text-based controls can also be rendered
graphically: pushbuttons, radiobuttons, and checkboxes.  (Scrollbars were
always graphical.)

Most of the graphics on word-processor toolbars are pushbuttons, with the
exception of a few radiobuttons.  Things like line spacing and text
justification are really radiobuttons, and these properties are really
adjectives: singlespaced, left justified etc.

I don't think that there is much confusion about this noun/verb/adjective
thing, however.  For one thing the pushbutton analogues are drawn as
buttons; they have a drop shadow and they move when pushed.  The graphical
checkboxes in Newswatcher and Eudora check and uncheck themselves when
clicked.  The graphical radio buttons hilite one of the choices at all
times and change in an obvious way when clicked.  The fact that these are
implemented as icons really isn't important, because they really do look
different and act differently from each other enough so that the user can
intuitively figure out how they work.

The problem is the difficulty in figuring out what a particular graphic
represents without having the text as a reminder.  Perhaps liberal use of
ballon help would give us the best of both worlds.

--
Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From Willie Abrams <[e-mail]>
Date: 22 Aug 1994 13:36:19 GMT
Organization: OU Health Sciences Center

In article <3331t7$[e-mail]> bgsuvax, [e-mail]
writes:
>  Take for example Word's toolbar that can be found in most of
>their apps now and can also be found in other vendor's apps
>(i.e. CodeWarrior).  The HIGs never evolved to encompass
>toolbars, hence the thread that started here some time back
>about toolbar icons representing nouns or verbs, and which
>was appropriate.

Toolbars are not cool, or good, or even mildly redeeming.
Come on, please, the goal of any good UI is to get the hell
out of the users way so that they can get their work done.

The icons in Toolbars don't make sense. They aren't consistent.
And why do I need a toolbar icon to save, open or cut, copy,
paste, etc. Ugh. I don't highlight an icon in the Finder and
click on a "copy" icon, why the heck should I want to in a
word processor or compiler.

Toolbars are not quickly removed or added, rarely are they
resizeable, and they almost always go horizontal. (Damnit,
most monitors are landscape oriented - now I have to decrease
even further my vertical space? No.)

I can't move'm, reshape them, nor can I tell what is going on
in my compiles without it being there.

And from the looks of it, Word 6 with all of its damn toolbars,
will be better known as "Honey, I shrunk the document window!"


Willie Abrams                                  [e-mail]
Telemedicine Software Guy                     OU Health Sciences Center

It's a classic Pincer's Movement. It can't fail against a ten-year-old!

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Mon, 22 Aug 1994 15:51:32 GMT
Organization: Process Control Center

In article <[e-mail]>, [e-mail]
(Pete Gontier) wrote:

> > While most programmers have followed the guidelines, there
> > are several apps out there that have had to break the HIGs
> > in order to do what was necessary.
>
> Examples being?

How about Pop-Up menus. Was a time, there was no such thing in HIG. I seem
to remember seeing them for the first time in dBase for Mac. Several
developers followed suit, the idea caught on, and pop-ups were canonized
in the HI chapter of IM IV. Hierarchical submenus were also officially
introduced in IM IV, but I'm sure that a couple of apps had introduced
this trick before it was ``canonized''.

Same for tri-state checkboxes. There's a human interface note that
acknowledges the appropriateness of tri-state objects and discusses the
solution used for menus that show state information (to wit, the Labels
menu in the Finder when the selected objects have different labels). The
note does not directly deal with the solution found in Microsoft products,
which, IMHO, is at least as good as the suggestion proposed in the note.

Facit: The Human Interface needs to grow (cf. _Macintosh Human Interface
Guidelines_, pp 38-40). As the book says, changes should be made
_cautiously_, with user testing and a sense of aesthetic compatibility
with the existing interface elements.

There should be compelling reasons for developing a new interface element.
Changes should not be made arbitrarily.

--
Peter Castine               | C (n.): A programming language that is sort of
[e-mail]   | like Pascal except more like assembly except
Process Control Center      | that it isn't very much like either one, or
Technical University Berlin | anything else.                  -- Ray Simard

+++++++++++++++++++++++++++

>From [e-mail] (bgsuvax)
Date: 22 Aug 1994 16:46:48 GMT
Organization: Bowling Green State University

Willie Abrams <[e-mail]> writes:
>
> Toolbars are not cool, or good, or even mildly redeeming.
> Come on, please, the goal of any good UI is to get the hell
> out of the users way so that they can get their work done.

  For some of the Word commands they do act as shortcuts, and
they increase my productivity in those situations.
>
> The icons in Toolbars don't make sense. They aren't consistent.
> And why do I need a toolbar icon to save, open or cut, copy,
> paste, etc. Ugh. I don't highlight an icon in the Finder and
> click on a "copy" icon, why the heck should I want to in a
> word processor or compiler.

  Yes, icons for cut & paste are pretty pointless.  But the
beauty behind Word's toolbar is that it is *CUSTOMIZABLE*.
You can take out the 'Save' icon and replace it with a
'Save As' icon (for which there is either no keyboard command
equivalent or it is so esoteric that I can't ever remember it).
I don't set up the buttons for simple commands which the
keyboard equivalents are easily remembered.  I have buttons for
the ones that are (somewhat ;-) cryptic.  Granted, my settings
would confuse a newbie and also the icons that I have set for
the command hardly leave a clue as to what the command is, but
for me they make sense.

>
> Toolbars are not quickly removed or added, rarely are they
> resizeable, and they almost always go horizontal. (Damnit,
> most monitors are landscape oriented - now I have to decrease
> even further my vertical space? No.)
>
  These features are customizable in Word.  Verticle on either
side is OK.

> I can't move'm, reshape them, nor can I tell what is going on
> in my compiles without it being there.
>
  Maybe they don't make alot of sense in CodeWarrior (I haven't
seen them yet... ;-)  That doesn't mean they don't have a place
in UI design.

> And from the looks of it, Word 6 with all of its damn toolbars,
> will be better known as "Honey, I shrunk the document window!"

  And if the toolbars are similar to the 5.1 version, then they
will not only be customizable but hideable also.  That means that
if you don't want to see 'em you can make 'em go away.

  Now don't get me wrong, I am not a big MS fan.  I think they
are a huge Goliath that will fall to a smaller David (Apple? ;-)
someday.  But the goal of this thread was to discuss the HIGs
and why Apple was abandoning them in 7.5.  I brought up the
toolbar thing because there is a market for them, and the HIGs
don't cover toolbars (yet?).

Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!

+++++++++++++++++++++++++++

>From [e-mail] (SCOTT I CHASE)
Date: 22 Aug 1994 15:37 PST
Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA

In article <[e-mail]>, [e-mail] (Peter Castine) writes...
>
>As one example, I was looking at the new(ish) AppleCD Audio Player. The
>only reason I even tried clicking on the little green triangle in the
>lower left corner was because I knew that the fore-runner software had a
>track list and I was sure that the newer software _must_ have a track list
>somewhere. I looked in the menus, to no avail, so I started clicking
>around and the mouse finally landed on said triangle. Voila! Success at
>last!
>
>So, in short: yes, this bothers me. Who else?

Me!  I just discovered this last night.  I was helping a friend set up
her 840 AV.  Having never used an AV Mac before, I was having fun playing
with all the neat tools.  I fooled around with the AppleCD Audio Player
for at least 15 minutes before I accidentally, at random, hit that
little green triangle.  That's a button?  Jeez.

-Scott
- ------------------                         Physics is not a religion.  If
Scott I. Chase                               it were, we'd have a much easier
[e-mail]                         time raising money. -Leon Lederman

+++++++++++++++++++++++++++

>From [e-mail]
Date: 22 Aug 94 16:44:49 MST
Organization: (none)

In article <33a9kj$[e-mail]>, Willie Abrams <[e-mail]> writes:
> In article <3331t7$[e-mail]> bgsuvax, [e-mail]
> writes:
>>  Take for example Word's toolbar that can be found in most of
>>their apps now and can also be found in other vendor's apps
>>(i.e. CodeWarrior).  The HIGs never evolved to encompass
>>toolbars, hence the thread that started here some time back
>>about toolbar icons representing nouns or verbs, and which
>>was appropriate.
>
> Toolbars are not cool, or good, or even mildly redeeming.
> Come on, please, the goal of any good UI is to get the hell
> out of the users way so that they can get their work done.
>
> The icons in Toolbars don't make sense. They aren't consistent.
> And why do I need a toolbar icon to save, open or cut, copy,
> paste, etc. Ugh. I don't highlight an icon in the Finder and
> click on a "copy" icon, why the heck should I want to in a
> word processor or compiler.
>

The only place where "Toolbars" make sense is where they have always been:


rulers -a convenient way to control lots of little options that can change
drastically depending on where you are in your document.

Rulers (toolbars) in this case allow you to not only control the parameters of
the document but also get visual feedback as to what they are.


The only other use that makes sense, H-I-wise, is when you use a certain
menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you
want it to appear on the toolbar because it is more convenient than using the
menu, and is more consistent that rearranging the menu-order to suit your whim
for what may be a specialized need in a specific document.

Hmmm... Does Word even allow document specific toolbars?


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Chuck Browne)
Date: 23 Aug 1994 00:16:47 GMT
Organization: Drexel University (Computing Services)

SCOTT I CHASE ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail] (Peter Castine) writes...
: >
: >As one example, I was looking at the new(ish) AppleCD Audio Player. The
: >only reason I even tried clicking on the little green triangle in the
: >lower left corner was because I knew that the fore-runner software had a
: >track list and I was sure that the newer software _must_ have a track list
: >somewhere. I looked in the menus, to no avail, so I started clicking
: >around and the mouse finally landed on said triangle. Voila! Success at
: >last!
: >
: >So, in short: yes, this bothers me. Who else?

: Me!  I just discovered this last night.  I was helping a friend set up
: her 840 AV.  Having never used an AV Mac before, I was having fun playing
: with all the neat tools.  I fooled around with the AppleCD Audio Player
: for at least 15 minutes before I accidentally, at random, hit that
: little green triangle.  That's a button?  Jeez.


That got me too! I found it totally by accident - I saw the triangle,
and thought it was just a power LED, just like on a non-virtual stereo.
When I accidentally clicked on it and the track list opened, I got that
"Hey, this program is like Myst in the puzzles that delight" feeling...

Chuck

: -Scott
: --------------------                         Physics is not a religion.  If
: Scott I. Chase                               it were, we'd have a much easier
: [e-mail]                         time raising money. -Leon Lederman

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Geweke)
Date: Mon, 22 Aug 1994 21:26:57 -0500
Organization: Michigan State University

In article <33a9kj$[e-mail]>, Willie Abrams <willie-
[e-mail]> writes:
> In article <3331t7$[e-mail]> bgsuvax, dnebing@
> andy.bgsu.edu writes:
> >  Take for example Word's toolbar that can be found in most of
> >their apps now and can also be found in other vendor's apps
> >(i.e. CodeWarrior).  The HIGs never evolved to encompass toolbars,
> >hence the thread that started here some time back about toolbar
> >icons representing nouns or verbs, and which was appropriate.
>
> Toolbars are not cool, or good, or even mildly redeeming.
> Come on, please, the goal of any good UI is to get the hell out of
> the users way so that they can get their work done.

Amen. Doesn't *anybody* here like the kind of application where you get one
big window to work on your document that takes up all of your monitor?
(Assuming, of course, the document's natural size is at least that big? :-)

> The icons in Toolbars don't make sense. They aren't consistent.
> And why do I need a toolbar icon to save, open or cut, copy, paste,
> etc. Ugh. I don't highlight an icon in the Finder and click on a
> "copy" icon, why the heck should I want to in a word processor or
> compiler.

You shouldn't, obviously.

Here's the major sticking point, too: Toolbars may or may not be an advantage
for the first-time user. (I tend to think they aren't.) However, they are a *
disadvantage* for anybody familiar with the program. Try this: Do these three
things, and see which is fastest. (1) Hit a command key for a menu command.
(I'm assuming you're at least a competent touch-typist). (2) Pull down the
menu to that command. (3) Find the toolbar button for that command and click
it.

Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably
faster than (3). (1) is by far the fastest.

In Windows, where every last app has a different key shortcut for Cut, Copy,
and Paste, toolbars may make sense; however, on the Mac, Command-X flies off
my fingertips while (find the right button) -> (maneuver to the tiny button) -
> (click the button) takes forever.

And finally, of course, as Apple has pointed out, menus have an "infinite"
height. I've got NowMenus set to automatically pull menus for me and leave
them down. I shove the mouse up to the top of the screen and bang, I've got
menus. It takes almost no effort at all.

> And from the looks of it, Word 6 with all of its damn toolbars, will
> be better known as "Honey, I shrunk the document window!"

No shit. Excel 4 is already bad enough. C'mon, let's all cheer on WordPerfect!

Cheers,
Andrew





+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Mon, 22 Aug 1994 23:33:18 -0700
Organization: Infinity Systems

In article <[e-mail]>,
[e-mail] (Andrew Geweke) wrote:

> Here's the major sticking point, too: Toolbars may or may not be an advantage
> for the first-time user. (I tend to think they aren't.) However, they are a *
> disadvantage* for anybody familiar with the program. Try this: Do these three
> things, and see which is fastest. (1) Hit a command key for a menu command.
> (I'm assuming you're at least a competent touch-typist). (2) Pull down the
> menu to that command. (3) Find the toolbar button for that command and click
> it.
>
> Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably
> faster than (3). (1) is by far the fastest.

Not true.  Often, (except for the highly consistent, often used command
key shortcuts like cut, copy, paste, save, etc) it is either just as fast
or faster to use a menu as it is to use a key command that corresponds
with it.

I don't want to go into all the details here because it is described in
the book _Tog On Interface_.  A couple relavent quotes, from page 26:

"We discovered, among other things, two pertinent facts:

  -- Test subjects consistently report that keyboarding is faster than mousing.

  -- The stopwatch consistently proves mousing is faster than keyboarding.

  The contradiction between user-experience and reality apparently forms
the basis for many user/developers' belief that the keyboard is faster."

The difference is that using the mouse to issue a command doesn't require
"high-level cognitive engagement" and is in fact "boring", according to
Tog.  Deciding what command keys ("abstract symbols") to use is a
"high-level cognitive function."  He goes on to say that, "Not only is
this decision not boring, the user actually experiences amnesia!  *Real*
amnesia!  The time-slice spent making the decision simply ceases to
exist."

Before you argue, please read the rest of this interesting article from
Tog's book.  It was also in the Apple Direct (or whatever it was called
then) magazine in August of 1989.


Now, when you think of the action in these terms, using a toolbar to
execute a command becomes a similar kind of "high-level cognitive
function."  This means that your mind is engaged in finding the icon that
represents the action you want to perform, and the same sort of rules
would seem to apply.

Now, as we all know, for some common actions, key commands are actually
faster than the mouse (for example, when demoing products, I've tried
using key commands for undo, cut, copy and paste, and it was always much
more difficult than using the keys).

In a similar fashion, for those people who decide to use a toolbar, I'm
sure that there are commands that they learn the positions/appearances of
in a similar fashion so as to be useful.  For instance, while generally
against toolbars, I do use the Metrowerks toolbar to issue the Run and
Preferences commands.  The majority of the others go unused, though.


> > And from the looks of it, Word 6 with all of its damn toolbars, will
> > be better known as "Honey, I shrunk the document window!"
>
> C'mon, let's all cheer on WordPerfect!

Which would be a good time to point out that WordPerfect has its own
version of 'toolbar hell', which occurs when you lose over half of your
screen if you show all of its toolbars simultaneously.  However, it does
so in a way that seems (to me as someone who hasn't actually _used_ the
program) like a much better scheme.

You basically have one bar that lets you access the others given on the
type of actions you wish to perform (by name, not icon you'll notice).  It
doesn't really fit the definition of toolbar as is being discussed in this
article, as these are sets of controls, not only icons, that are grouped
for doing things like changing text font, alignment, etc.

If I did much word processing, I'd try it out to see if it's as good an
idea as it looks.

Oh, and one last parting shot: I've noticed that other complex
applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark
Xpress, and many others get by fine without using toolbars at all.  Just
think of what life would be like if every program had a toolbar, with a
separate set of icons, commands, etc. (Makes me think of Windows,
actually...)

_troy
//////// //////___Troy [e-mail]___//
  //    //      Infinity Systems                                  //
 //    //  //  Redmond, Washington                               //
//    //////____________________________________________________//

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Tue, 23 Aug 1994 12:16:59 GMT
Organization: Adobe Systems Incorporated

Troy Gaul writes
> Oh, and one last parting shot: I've noticed that other complex
> applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark
> Xpress, and many others get by fine without using toolbars at all.  Just
> think of what life would be like if every program had a toolbar, with a
> separate set of icons, commands, etc. (Makes me think of Windows,
> actually...)

We have something called the "toolbar pact" among the Photoshop engineering
team. Collectively, we will stop at nothing to prevent toolbars from
creeping into the app. On the other hand the reward for adding a cool new
floating palette is at least a free beer. Go figure :-)
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
 Please do not change color while I am talking to you -- MC 900 Ft Jesus.

+++++++++++++++++++++++++++

>From [e-mail] (bgsuvax)
Date: 23 Aug 1994 14:34:48 GMT
Organization: Bowling Green State University

[e-mail] writes:
>
> The only place where "Toolbars" make sense is where they have always been:
>
> The only other use that makes sense, H-I-wise, is when you use a certain
> menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you
> want it to appear on the toolbar because it is more convenient than using the
> menu, and is more consistent that rearranging the menu-order to suit your whim
> for what may be a specialized need in a specific document.
>
  How about when an app (like Word) has so many menu items that the
frequently used menu items are far down in the menu, so far that the
menu has to scroll?

> Hmmm... Does Word even allow document specific toolbars?
>
  No, but you can configure it to contain customized commands.

  Dave

  (p.s. Down with MicroSoft [i.e. I am not an MS-lover!] ;-)

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!

+++++++++++++++++++++++++++

>From [e-mail] (bgsuvax)
Date: 23 Aug 1994 14:46:32 GMT
Organization: Bowling Green State University

[e-mail] (Andrew Geweke) writes:
> Try this: Do these three
> things, and see which is fastest. (1) Hit a command key for a menu command.
> (I'm assuming you're at least a competent touch-typist). (2) Pull down the
> menu to that command. (3) Find the toolbar button for that command and click
> it.
>
> Unless the toolbar buttons are at least 40x40 pixels, I think (2) is probably
> faster than (3). (1) is by far the fastest.

  I have one example which will prove you wrong.  On my Word toolbar,
I have customized the toolbar.  One of the icons I have set up as
the little paintbrush, and the command associated with it is
'Insert Graphic'.  There is no key command normally associated with
this command.  It is also far down the menu so that I have to scroll
to get to it.  In this situation, the icon is easy to identify and is
much faster than trying to get to the menu.

  It is not always the case that toolbars are either good or bad.
It is a personal preference, just like picking a big-blue box or
a Mac.  So whether you like them or you don't is not the question.
How the HIGs should standardize them is the question.

Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 23 Aug 1994 08:07:03 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]>
[e-mail] (Troy Gaul) writes:

>Anyway, I'd like to hear from some of the Apple people who are on the list
>as to how this stuff goes on.  How do these designs get into products?  I
>understand that there was one person in particular who did most of the
>designs for the color icons when System 7 was released, why isn't there a
>similar person who could enforce some amount of user interface
>consistency?

Apple doesn't write all of its own software. For example Apple Guide
was written by a third party. That third party is the one who
wrote the IDE drivers for the new computers I believe.

That's just two cases that I know about. Looks like 7.5 is full
of Third Party stuff. Why they didn't include your WDEF is
beyond me.


>//////// //////___Troy [e-mail]___//
>  //    //      Infinity Systems                                  //
> //    //  //  Redmond, Washington                               //
                ^^^^^^^^^^^^^^^^^^^
Getting to close to the evil empire eh? Can you feel the dark side
of the force? Obiwan may be your only hope. :-)





Xavier

--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 23 Aug 1994 08:19:51 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Mark Hanrek) writes:
>Maybe that analogy is useful in this discussion.
>
>Today, we can get into a 1965 Galaxie 500, or a 1994 Supra, and easily
>know what to do to drive either of them.

But do you know how to turn on the lights or High Beams? What about
air conditioning? When ever you get into a car you never been in before
it takes a while to find out where these things are and how they work.
When car companies started using icons it got worse.


Xavier





--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From Willie Abrams <[e-mail]>
Date: 23 Aug 1994 13:34:08 GMT
Organization: OU Health Sciences Center

In article <[e-mail]> Zalman Stern,
[e-mail] writes:
>We have something called the "toolbar pact" among the Photoshop
engineering
>team. Collectively, we will stop at nothing to prevent toolbars from
>creeping into the app. On the other hand the reward for adding a cool
new
>floating palette is at least a free beer. Go figure :-)

Good. I am happy. Maybe you all can start redesigning
that control palette in PageMaker.

Palettes are infinitely better than toolbars
as they are moveable (not just the sides of the screens),
easily closed (Wow, I can click the close box to make it go away.
What a concept!), and they follow function. I can sit down at
about any copy of Photoshop or Illustrator and work with
any users setup. This is because the palettes follow a particular
function, not just any arbitrary user configuration.

Toolbars were invented by Microsoft so that they wouldn't
have to do palettes. I refuse to accept a copout design as
standard interface, or even blessed HIG, when palettes simply
work better.

Willie Abrams                                  [e-mail]
Telemedicine Software Guy                     OU Health Sciences Center

It's a classic Pincer's Movement. It can't fail against a ten-year-old!

+++++++++++++++++++++++++++

>From [e-mail] (Pat LaVarre)
Date: 23 Aug 1994 17:32:59 GMT
Organization: Loral Federal Systems - Manassas, VA

Yea.  I think of a toolbar like a mini-desktop: a place where I can build my own
collection of data & tools.  For example, by putting a folder of aliases on the
desktop, I build a widget that works a lot like the Apple menu, without mucking
up the Apple menu that people generally expect.

--
Pat LaVarre   [e-mail]
The ASCII punctuation set here is !"#$%&'()*+,-./ :;<=>?@ [\]^_` {|}~

+++++++++++++++++++++++++++

>From [e-mail] (GBolsinga)
Date: 23 Aug 1994 14:40:12 -0400
Organization: America Online, Inc. (1-800-827-6364)

My two Cents:

I don't care if there are toolbars or not.  I just want to be able to get
rid of them if I want (which is usually true).

Greg
MPI Multimedia

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Tue, 23 Aug 1994 18:18:23 GMT
Organization: Will hack for food

Mark Hanrek ([e-mail]) wrote:

> I have come to discover that one of the reasons things are this way is
> because programmers aren't as demanding as they could/should be.

> A majority accept things too easily, and adapt to the way things are too
> easily.

> Often, programmers figure that if they don't understand something, it is
> their fault, and then won't say anything.

> Our tools ARE pretty crummy, yet look at the amazing and sophisticated
> things we create with them routinely for others.

> Why don't we want tools that are equally sophisticated?  Why do we put
> ourselves through building fine creations with just a screwdriver and a
> hammer? :)

I think the main reason is that we are more interested in creating than
complaining (except for whining on c.s.m.p of course ;).  I don't know
about you, but I've been under severe deadlines on my past 5 projects
and don't have time to whine about the tools.  I just try to find ones
that work and cope with it.

God, I love creating though.

Jon

+++++++++++++++++++++++++++

>From [e-mail] (Francis H Knight)
Date: Tue, 23 Aug 1994 21:53:37 GMT
Organization: Hertfordshire Mac Oasis

I tend to share the majority concern for the Mac's 'disippating' human
interface. I got to wondering what the simplest explanation for this
state of affairs might be. Knowing what that was could provide an
insight into the way to fix it.

I've come to the conclusion that in the battle with Macrosoft, Apple has
allowed Windows to close to a sufficiently short range that the most
effective tactical ammunition now is the 'bullet point'. Most consumers
seem easily swayed by what they see in the press, and a comparison of
feature lists is staple fare for computer journalists.

On the surface, one of the best things about System 7.5 is the bundling
of MacTCP, but when you read that Chicago is slated to incorporate a TCP
stack, and to be promoted as 'Internet-Ready', or some such slogan, then
you could be forgiven for suspecting that Apple is now merely a reactive
organisation.

If there is a strategy to move out of range again, as opposed to a
tactic for short-term survival, then maybe OpenDoc is it. I just hope
it's not too radical for MIS types to contemplate embracing. I can
imagine them fearing facing a choice between an administrative nightmare
and software anarchy. UK MacUser has quotes from Microsoft who believe
these fears will work in their favour.



Francis

+++++++++++++++++++++++++++

>From [e-mail]
Date: 23 Aug 94 15:22:30 MST
Organization: (none)

In article <33d1e8$[e-mail]>, [e-mail] (bgsuvax) writes:
> [e-mail] writes:
>>
>> The only place where "Toolbars" make sense is where they have always been:
>>
>> The only other use that makes sense, H-I-wise, is when you use a certain
>> menu-item a LOT that happens to be nested deep in a hierarchical menu. THEN you
>> want it to appear on the toolbar because it is more convenient than using the
>> menu, and is more consistent that rearranging the menu-order to suit your whim
>> for what may be a specialized need in a specific document.
>>
>   How about when an app (like Word) has so many menu items that the
> frequently used menu items are far down in the menu, so far that the
> menu has to scroll?
>

Nested, long [scrolling] list, same bad design, IMHO...

>> Hmmm... Does Word even allow document specific toolbars?
>>
>   No, but you can configure it to contain customized commands.
>

Decent. Does it allow Applscript-attachability/tinkerability to appear?

>   Dave
>
>   (p.s. Down with MicroSoft [i.e. I am not an MS-lover!] ;-)
>


MicroSoft-lovers don't admit to their bad habits in public (from the
undiscovered Notebooks of Lazurus Long)



Lawson

+++++++++++++++++++++++++++

>From Ross Scott Rubin <[e-mail]>
Date: Tue, 23 Aug 1994 23:01:43 GMT
Organization: Salomon Brothers Inc

In article <[e-mail]> Chris Wysocki, [e-mail]
writes:
>I wholeheartedly concur.  Apple has done far too little in recent
>years to promote UI consistency across applications.  Their reluctance
>to provide standard implementations of UI features such as floating
>windows, menus with multiple-modifier keyboard shortcuts, and basic
>controls such as up-down arrows, sliders and progress bars have forced
>developers to implement these features themselves, with varying and
>sometimes inconsistent results.  At the Worldwide Developers
>Conference in May some Apple engineers spoke in nebulous terms about
>future UI enhancements which are coming down the road, but it struck
>me and others with whom I spoke as too little, too late....

An excellent response, Chris. I believe System 8 is supposed to restore
consistency toward creating a Mac interface in the world beyond the black
and white screen.

+-- +--\ --- ---------------------------------------------------------------+
|   |  /  | Ross Scott Rubin      | Internet: [e-mail]                |
+-+ +-<   | Salomon Brothers, Inc.| AOL, eWorld: rossrubin | CIS:72137,2627 |
  | |  \  |    "Opinions are mine alone. Who else would admit to them?"     |
--+ +--/ --- ---------------------------------------------------------------+

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 24 Aug 1994 01:11:25 GMT
Organization: Apple Computer

netcom.com!kira!davidjohn,  writes:
> Individually, many of these don't look that bad, I suppose (but, that's
> another issue, really).  However, as I recall, one of the advertised
> strengths of the Macintosh, in past years, was its highly consistent
> interface...

This discussion came up after WWDC when people were playing with the beta
version of 7.5. The fundamental issue is that the HI has to move forward;
that the old mostly black and white interface is getting old. Future system
software will have drastic changes, but there are incremental ones in 7.5.

> - a strange little thing for 'post-it' notes

Yeah, I wrote that. I did my own WDEF because the notes have to be tiny and
inconspicuous. There used to be some shareware post-it apps that used normal
WDEFs, and they looked pretty godawful.

> - the Find File windows have a funky styled background

So do the majority of new commercial products these days, or at least a gray
background. There's no law saying all windows have to be white.

> - A window that is reminiscent of the 'palette' titlebar, but with close
>   and zoom boxes.

That's the new official palette WDEF, right in the System file. Many people
do prefer e.g. the Infinity WDEF, but apparently the HI people had good
reasons for making this one look the way it does.

As for buttons, there are official Apple HI guidelines for 3D buttons. Check
out develop issue 17 (or was it 16?) which has an article complete with
pictures and sample code.

> What kind of message is this
> sending to developers? It seems to me it's something like, 'Sure, go ahead,

> bypass the toolbox

Writing new WDEFs or CDEFs is not 'bypassing the toolbox', at least not in
the same sense that slamming bits onto the screen is. The Window Manager is
meant to be extensible. It's hoped that one will have a good reason for using
a custom WDEF, but at least in my case I feel that I did. (It would certainly
have been a zillion times easier for me to use a normal WDEF; writing WDEFs
from scratch is a pain.)

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (William Uther)
Date: 24 Aug 1994 11:28:31 +1000
Organization: Basser Dept of Computer Sciece, Uni of Sydney, Australia

In article <[e-mail]>,
Troy Gaul <[e-mail]> wrote:
>In article <[e-mail]>,
>[e-mail] (Andrew Geweke) wrote:

>I don't want to go into all the details here because it is described in
>the book _Tog On Interface_.  A couple relavent quotes, from page 26:
>
>"We discovered, among other things, two pertinent facts:
>
>  -- Test subjects consistently report that keyboarding is faster than mousing.
>
>  -- The stopwatch consistently proves mousing is faster than keyboarding.
>
>  The contradiction between user-experience and reality apparently forms
>the basis for many user/developers' belief that the keyboard is faster."
>
  This raises an intesting marketing point.  From a purely pragmatic point of
view, the software producer wants the user to like the product rather than the
product actually being useful for the user.  In this case pleasing the user
would mean that you use keyboard commands because the user thinks they are
being faster.
  I'm not saying I condone the practice, but I think that if one were a
complete #@%*!!$@ one might act like this.

\x/ill       :-}

[e-mail]
#include <stddisclaimer.h>


+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Wed, 24 Aug 1994 11:32:36 GMT
Organization: Process Control Center

In article <[e-mail]>, [e-mail] (Zalman
Stern) wrote:

> Troy Gaul writes
> > Oh, and one last parting shot: I've noticed that other complex
> > applications, including Photoshop, Illustrator, Freehand, PageMaker, Quark
> > Xpress, and many others get by fine without using toolbars at all.  Just
> > think of what life would be like if every program had a toolbar, with a
> > separate set of icons, commands, etc. (Makes me think of Windows,
> > actually...)
>
> We have something called the "toolbar pact" among the Photoshop engineering
> team. Collectively, we will stop at nothing to prevent toolbars from
> creeping into the app. On the other hand the reward for adding a cool new
> floating palette is at least a free beer. Go figure :-)

Question:

What's the difference between a toolbar and a palette?

Gee, I don't *know* the answer either. I'd suggest that a well thought-out
toolbar can make sense in a UI design (actually, I have done so in other
posts). Buttons as shortcuts for frequent tasks actually makes sense.

However, I also find implementation in MS products unsatisfying. I think
the problem is that for the activities in the toolbar, the icons are too
difficult to associate with the actions. Style attributes work well
enough, but Save? Undo?--as The Book says in Icons, Chapter II, Verse 28
``Verily, I sayeth unto you, there is a time for icons and a time for
text; a time to sow, and a time to reap. And he that knoweth the
difference shall find a place at the HI beer bust.''

--
Peter Castine               | C (n.): A programming language that is sort of
[e-mail]   | like Pascal except more like assembly except
Process Control Center      | that it isn't very much like either one, or
Technical University Berlin | anything else.                  -- Ray Simard

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Wed, 24 Aug 1994 12:14:58 GMT
Organization: Process Control Center

In article <33d248$[e-mail]>, [e-mail] (bgsuvax) wrote:

> [e-mail] (Andrew Geweke) writes:
> > Try this: Do these three
> > things, and see which is fastest. (1) Hit a command key for a menu command.
> > (I'm assuming you're at least a competent touch-typist). (2) Pull down the
> > menu to that command. (3) Find the toolbar button for that command and
click
> > it.
> >
> > Unless the toolbar buttons are at least 40x40 pixels, I think (2) is
probably
> > faster than (3). (1) is by far the fastest.
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~

Do you have any studies to confirm that? There are several studies that
show (2) to be the fastest in most cases.

Don't believe it? Do some research (either in the lab or the library--in
the library you should look up Card's work at PARC in the early 80's).

>
>   I have one example which will prove you wrong.  On my Word toolbar,
> I have customized the toolbar.  One of the icons I have set up as
> the little paintbrush, and the command associated with it is
> 'Insert Graphic'.  There is no key command normally associated with
> this command.  It is also far down the menu so that I have to scroll
> to get to it.  In this situation, the icon is easy to identify and is
> much faster than trying to get to the menu.

Since you can configure your menus in Word pretty much however you want,
there are a couple of alternatives, such as defining a keyboard shortcut
for the command. However, the toolbar is not a bad solution.

BTW, have you tried putting the toolbar on the right side of the screen?
I've found that a much better solution. (Personal preference)

--
Peter Castine               | C (n.): A programming language that is sort of
[e-mail]   | like Pascal except more like assembly except
Process Control Center      | that it isn't very much like either one, or
Technical University Berlin | anything else.                  -- Ray Simard

+++++++++++++++++++++++++++

>From [e-mail] (Charlie Wood)
Date: Wed, 24 Aug 1994 09:12:34 -0600
Organization: Illuminati Online

This discussion really hits home with me, since we have an internal
user-interface war raging at my company. The problem is exaggerated by the
fact that half of the development staff consists of Windows programers. No
offense.

I wholeheartedly agree with the low opinion of toolbars voiced here (and
totally agree that MS' UI people should be locked up). I've read Tog and
have seen His Way. I'm definitely a Mac purist at heart, even though I did
design that one five-level-deep hierarchical popup menu with 1400 items in
it. (I *swear* it was the best way! ;-)

But, in reading this thread, I find myself wishing for a "Next Article"
button in NewsWatcher. Yes, I can type cmd-I, but when I'm doing almost
everything else with the mouse, I wish I could access this
highly-repetitive function in the same way. Yes, of course I can select
the menu item with the mouse, but that's not nearly as elegant as a
button-click would be.

However, if Peter Lewis ever adds a cut, copy, or paste button, I will
become a DOS programmer just out of spite.

Regards,
Charlie

--
Charlie Wood     |     Wanna see me travel into the future?
[e-mail]     |     Wanna see it again?

+++++++++++++++++++++++++++

>From [e-mail] (Lee Fyock)
Date: Wed, 24 Aug 1994 10:40:24 -0400
Organization: The MathWorks, Inc.

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:

> > - the Find File windows have a funky styled background
>
> So do the majority of new commercial products these days, or at least a gray
> background. There's no law saying all windows have to be white.

No, there's no law...  But page 258 of the Mac HIG says that "Apple's goal
in adding color to the interface is to enhance meaning, not just to color
things to improve aesthetics".

I think that the problem (if there is one) in the Find File windows is
that the background isn't a smooth gray (as kind of recommended on pg.
265), but is a gray pattern, unlike any other window background I've ever
seen.

> > - A window that is reminiscent of the 'palette' titlebar, but with close
> >   and zoom boxes.
>
> That's the new official palette WDEF, right in the System file. Many people
> do prefer e.g. the Infinity WDEF, but apparently the HI people had good
> reasons for making this one look the way it does.

It scares me when people say "they must have had a good reason..."  How do
we know that it wasn't just some co-op?  :-)

> As for buttons, there are official Apple HI guidelines for 3D buttons. Check
> out develop issue 17 (or was it 16?) which has an article complete with
> pictures and sample code.

But why weren't CDEFs included?  Why aren't the CDEFs part of the system?
Why isn't the progress bar documented and standard for the system?
Developers are forced to write their own.  Then, when Apple changes the
appearance of windows or controls, those developers' apps look goofy.  I
remember several programs that drew their own grow icons in windows --
when System 7 came out, they were instantly dated.  That's not a great
example, since they shouldn't have drawn the grow boxes that way, but how
about apps' floating window WDEFs?  We finally have a standard, but how
long have commercial apps been using their own WDEFs for floating
windows?  Too long...


Just my 2 cents.


Have fun!
Lee


- ------------------------------------------------------------------
Lee Fyock                                    "I think I would remain
[e-mail]                                perfectly still."

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 24 Aug 1994 22:34:38 GMT
Organization: Apple Computer

In article <[e-mail]> Robert Mah,
[e-mail] writes:
> One would expect that with Don Norman in
> charge (he is in charge of HIG isn't he?) that HIG would be less worried
> over the "look" and more about the "feel".  That they would hire fewer
> graphic designers and more people versed in psychology and sociology.

Apple has a mix of both, and both types of designers are involved in
products. In the 3rd party utilities I think more attention went to the
appearance since that's easier to change when the code comes from somebody
outside; although there were changes in behavior dictated during the process
(I had to deal with several of them.)

> The sticky note windows are even more bothersome.

I agree that the windows are nonstandard, but I really, really didn't think I
had a choice. Doing post-its with normal WDEFs looks really ugly. Just try it
sometime and see what you think, or look at any of the freeware post-it
programs. They suck.

> Looking farther into the future, does the pre-emption of the "File" menu
> with a "Document" menu in OpenDoc bother anyone?  This seems to me to be
> a gratuitous market decision in a vain attempt to differentiate" OpenDoc
> from the current crop of applications.

There were two reasons -- (1) to make it clear that the user is in an OpenDoc
document and not in a traditional app; this is not just a marketing thing,
since OpenDoc documents have capabilities that regular apps don't and it's
important for the user to have an idea of which they're in. And (2) to get
away from the document==file thing that may not be true in the future with
more sophisticated data storage schemes. There is nothing that says an
OpenDoc document has to live in a file.
You also mentioned the problem of menubar real estate -- most of the problems
in this regard happen on non-English systems (esp. German and French). In
those languages the name of the File menu is already more equivalent to the
English "Document" and there would not be a hit in menu size.

There's room for debate here, but don't jump to the conclusion that people at
Apple are idiots or totally incapable of making decisions, OK? It gets a bit
tiresome debating against that attitude.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 24 Aug 1994 23:39:54 GMT
Organization: Apple Computer

Andrew Southwick, [e-mail] writes:
> This really (constantly) surprises me.  THIS is the part of the human
> interface that APPLE should be working on.  Why do I have to create
> all these controls by hand?  Why has Apple refused to develop these
> interface enhancements?

Because there's a big difference between the HI designers designing the best
way to implement a feature, and engineering actually implementing the feature
in a standard portable way (e.g. a CDEF) that will be fully tested and
released to developers.
It's hard enough just getting the major stuff that only Apple can do out the
door; usually lower-priority things like writing a date/time control either
never make it to the product stage or are canceled so their resources can be
transferred to larger projects.
On the other hand, I think that writing these kinds of controls and things is
something that'd be great for DTS to do -- they could release them with
source code both as stuff for developers to take advantage of, and as sample
code for how to write your own.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Tim Dierks)
Date: Wed, 24 Aug 1994 23:45:45 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
netcom.com!kira!davidjohn (David John Burrowes) wrote:
... Comments on the user interface consistency of System 7.5 ...

Elizabeth Moller of our Human Interface group wrote this response to David
and asked me to post it.

- - - - - - - - -

David,
Your comments got forwarded (several times) to me here in the AppleSoft
Human Interface Design Center.  I was disappointed in the quality of the
HI of the System 7.5 additions.  I think that some of the goodies are OK
using non-standard windows (sticky notes and launcher) because the design
is key to the usability.  I do wish we had the appropriate items in the
toolbox (especially the icon buttons), but that will have to wait.  There
is no HI excuse for the CD Player and the patterns in the backgrounds of
the DAs.  Our marketing folks felt they were appropriate.  The palette
(AKA utility window) titlebar is now avialable in the system.

We're working hard to get our toolbox updated so we have a leg to stand
on.  Unfortunately consistency for the user (in the long run) doesn't seem
to be a big selling point with our marketing dept. System 7.5 has made our
job harder for the reasons you have pointed out.  I hope there are
developers out there that still believe that standard is best.

Elizabeth Moller
[e-mail]

--
Tim Dierks
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bob Kenyon)
Date: Wed, 24 Aug 1994 22:47:12 GMT
Organization: Lockheed Missiles & Space Co.

In article <[e-mail]>, [e-mail] (SCOTT I
CHASE) wrote:

> In article <[e-mail]>,
[e-mail] (Peter Castine) writes...
> >
> >As one example, I was looking at the new(ish) AppleCD Audio Player. The
> >only reason I even tried clicking on the little green triangle in the
> >lower left corner was because I knew that the fore-runner software had a
> >track list and I was sure that the newer software _must_ have a track list
> >somewhere. I looked in the menus, to no avail, so I started clicking
> >around and the mouse finally landed on said triangle. Voila! Success at
> >last!
> >
> >So, in short: yes, this bothers me. Who else?
>
> Me!  I just discovered this last night.  I was helping a friend set up
> her 840 AV.  Having never used an AV Mac before, I was having fun playing
> with all the neat tools.  I fooled around with the AppleCD Audio Player
> for at least 15 minutes before I accidentally, at random, hit that
> little green triangle.  That's a button?  Jeez.

Hang on a sec. It just struck me that the little triangle is exactly
analogous to the triangle that appears next to the names in the "List
View" of a Finder window. When you click on those triangles, they rotate
ninety degrees and the contents "spill" out. This triangle also appears in
a number of other programs, one of which is InterSLIP.

It's a new paradigm, but it's not unreasonable.

Bob

--
Bob Kenyon ([e-mail])            | "It's called Windows
Spacecraft Engineering & Technology               |  because it's a real
Lockheed Missiles & Space Co., Sunnyvale, CA USA  |  pane." - Dave Barry

+++++++++++++++++++++++++++

>From [e-mail] (Eric G. Miller)
Date: Wed, 24 Aug 1994 22:29:48 -0500
Organization: Express Access Online Communications, USA

In article <[e-mail]>, [e-mail] (Charlie
Wood) wrote:
> But, in reading this thread, I find myself wishing for a "Next Article"
> button in NewsWatcher. Yes, I can type cmd-I, but when I'm doing almost
> everything else with the mouse, I wish I could access this
> highly-repetitive function in the same way. Yes, of course I can select
> the menu item with the mouse, but that's not nearly as elegant as a
> button-click would be.

Yes, the ability to repeat the same action over and over by just clicking
the mouse button (with one hand) is really great for those times when you
are trying to enjoy a really slimy/greasy snack (with the other hand).
Toolbars may stink but they rank well above keyboard condoms in my book.
The human-computer interface is neither as time-tested nor as vital as the
human-snack food interface. Perhaps what really needs more work is the
computer-snack food interface...
             Bottoms up!
                          -  egm

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 25 Aug 1994 05:56:52 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] wrote:

> David,
 I was disappointed in the quality of the
> HI of the System 7.5 additions.  I think that some of the goodies are OK
> using non-standard windows (sticky notes and launcher) because the design
> is key to the usability.  There
> is no HI excuse for the CD Player and the patterns in the backgrounds of
> the DAs.  Our marketing folks felt they were appropriate.  The palette
> (AKA utility window) titlebar is now avialable in the system.
>
> We're working hard to get our toolbox updated so we have a leg to stand
> on.  Unfortunately consistency for the user (in the long run) doesn't seem
> to be a big selling point with our marketing dept. System 7.5 has made our
> job harder for the reasons you have pointed out.  I hope there are
> developers out there that still believe that standard is best.
>
> Elizabeth Moller
> [e-mail]



I guess this is a good news-bad news situation.  The good news is that
there ARE people at Apple who know about and care about HI.  The bad news
is that they are  overruled by marketing types.


(I had to delete some of the quoted message because my silly newsserver
won't let me post messages where the new text is less than the included
text.)

--
Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From Willie Abrams <[e-mail]>
Date: 25 Aug 1994 13:32:01 GMT
Organization: OU Health Sciences Center

In article <[e-mail]> Tim Dierks,
[e-mail] writes:
>David,
>Your comments got forwarded (several times) to me here in the AppleSoft
>Human Interface Design Center.  I was disappointed in the quality of the
>HI of the System 7.5 additions.  I think that some of the goodies are OK
>using non-standard windows (sticky notes and launcher) because the design
>is key to the usability.  I do wish we had the appropriate items in the
>toolbox (especially the icon buttons), but that will have to wait.  There
>is no HI excuse for the CD Player and the patterns in the backgrounds of
>the DAs.  Our marketing folks felt they were appropriate.  The palette
>(AKA utility window) titlebar is now avialable in the system.
>
>We're working hard to get our toolbox updated so we have a leg to stand
>on.  Unfortunately consistency for the user (in the long run) doesn't
seem
>to be a big selling point with our marketing dept. System 7.5 has made
our
>job harder for the reasons you have pointed out.  I hope there are
>developers out there that still believe that standard is best.
>
>Elizabeth Moller
>[e-mail]
>
>--
>Tim Dierks
>[e-mail]

Tim, thanks for posting this one.

Why isn't Elizabeth (or anyone in HIG) being heard? Is marketing truly
to blame for all of this? If so, I am much more worried about the HI
stuff now than when I was at WWDC. At least there, it seemed, that
HI was a critical point in the entire Apple world view.

What was the quote, "The user is the center of everything we do." -
I hope for all of our sakes, as Apple developers, employees and users,
that the quality of the Human-Machine interaction remains paramount
in our minds. And, it would seem, the best group to steer and maintain
that quality at Apple is the HIG, not marketing.

Willie Abrams                                  [e-mail]

       Less is more. God is in the details. - Mies van der Rohe

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Fri, 26 Aug 1994 12:33:47 +1200 (NZST)
Organization: (none)

[e-mail] (Charlie Wood) writes:
> But, in reading this thread, I find myself wishing for a "Next Article"
> button in NewsWatcher. Yes, I can type cmd-I, but when I'm doing almost
> everything else with the mouse, I wish I could access this
> highly-repetitive function in the same way. Yes, of course I can select
> the menu item with the mouse, but that's not nearly as elegant as a
> button-click would be.

What are you doing with the mouse in NewsWatcher?  The spacebar, or the
keypad 0 work pretty well for "next article".

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Mike Balfour)
Date: 25 Aug 1994 15:48:34 GMT
Organization: Overload Engineering

In article <33i6gh$[e-mail]>, Willie Abrams
<[e-mail]> wrote:

> Why isn't Elizabeth (or anyone in HIG) being heard? Is marketing truly
> to blame for all of this? If so, I am much more worried about the HI
> stuff now than when I was at WWDC. At least there, it seemed, that
> HI was a critical point in the entire Apple world view.
>
> What was the quote, "The user is the center of everything we do." -
> I hope for all of our sakes, as Apple developers, employees and users,
> that the quality of the Human-Machine interaction remains paramount
> in our minds. And, it would seem, the best group to steer and maintain
> that quality at Apple is the HIG, not marketing.
>

Well, here's a little something to consider before jumping on Apple.  It
could be that they're ditching some of these standards because the user
wants it that way (of course, what's *best* for the user doesn't
matter:).  When someone's out there trying to decide which computer to
buy, and they see a Mac with a CD-ROM drive with this cool window on the
screen that controls it - a window that will make their computer look cool
to their friends - it appeals to them.  It's what they want, so they buy
it.

While HIG is best suited for determining how to make the machine easiest
to use, marketing really is the best group for determining what the user
wants, unfortunately.  In my opinion, this *does* seem like a rather blind
way of looking at things, 'cause the easiest-to-use machine is ultimately
what the user will want, if it's done correctly.  Candy features are nice,
and they'll sell things, and they appeal to people, but they'll only give
you empty calories and rot your teeth :).

(BTW Jens, don't take offense at my calling the post-it notes that you
designed "candy".  I'm a chocoholic.:)

To sum up:  Don't jump on Apple's case too quickly.  As a company, they're
not here to tell us what's best for us; they're here to give us what we
want, and what we ask for...

Should I smiley that last sentence?

MB
--
- --------------------------------+--------------------------------
Mike Balfour, Partner             | BS/MS Candidate - ECMP
Overload Engineering              | Case Western Reserve University
"New Ideas for a Brighter Future" | Cleveland, OH

+++++++++++++++++++++++++++

>From Willie Abrams <[e-mail]>
Date: 26 Aug 1994 13:57:42 GMT
Organization: OU Health Sciences Center

In article <[e-mail]> Mike Balfour,
[e-mail] writes:
>While HIG is best suited for determining how to make the machine easiest
>to use, marketing really is the best group for determining what the user
>wants, unfortunately.  In my opinion, this *does* seem like a rather
blind

I agree. Case in point, ideally the interaction should go like this:

Marketing: The user needs to be able to do this.

Engineering: We can program anything... :-)

HIG: This is what the user experience should be.

Not marketing deciding what interface is appropriate, and
HIG not being utilized for their expertize.

I am not jumping on Apple, per se, but I use and program Macs
by choice. The entire user experience and consistency of the
Mac is the reason I use them. The minute I start getting visually
assualted by my Macintosh is the minute I start panicking.

The moment I spend trying to figure out why I can't find the
program list in the CD remote, or why the find file box has got
a weirdo color scheme unlike the rest of Mac, is a moment lost
for no good reason. Do it consistently or don't do it at all.

I won't standby and watch my Mac turn into an enitre mish-mash
of metaphors, visual clues, and interface elements. I will turn
it off first.

Willie Abrams                                  [e-mail]

       Less is more. God is in the details. - Mies van der Rohe

+++++++++++++++++++++++++++

>From [e-mail] (Hank Gillette)
Date: 26 Aug 1994 23:05:05 GMT
Organization: esl.com

In article <33d248$[e-mail]>, [e-mail] (bgsuvax) wrote:

>   I have one example which will prove you wrong.  On my Word toolbar,
> I have customized the toolbar.  One of the icons I have set up as
> the little paintbrush, and the command associated with it is
> 'Insert Graphic'.  There is no key command normally associated with
> this command.  It is also far down the menu so that I have to scroll
> to get to it.  In this situation, the icon is easy to identify and is
> much faster than trying to get to the menu.

But there's nothing stopping you from assigning a key command to 'Insert
Graphic', since Word allows you to assign key commands to any command.

Hank Gillette

--

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sat, 27 Aug 1994 00:08:29 -0500
Organization: One Step Beyond

Willie Abrams <[e-mail]> wrote:

) The moment I spend trying to figure out why I can't find the program
) list in the CD remote, or why the find file box has got a weirdo color
) scheme unlike the rest of Mac, is a moment lost for no good reason.
) Do it consistently or don't do it at all.
)
) I won't standby and watch my Mac turn into an enitre mish-mash of
) metaphors, visual clues, and interface elements. I will turn it off
) first.

Amen.  Only on the Mac could you have the audience of a demo tell the
demonstrator how to access functions that they've never seen.  I've seen
it happen.  The reason it can happen is the interface consistency between
applications.  This is more than just conforming to guidelines, it also
includes being aware that _other_ people may have had the same interface
problem and making your solution similar to theirs.

I'm afraid that Apple is losing it's way.  I wonder how much the top execs
actually use their Macs for more than writing memos.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (bgsuvax)
Date: 27 Aug 1994 18:00:19 GMT
Organization: Bowling Green State University

[e-mail] (Hank Gillette) writes:
> In article <33d248$[e-mail]>, [e-mail] (bgsuvax) wrote:
>
>>   I have one example which will prove you wrong.  On my Word toolbar,
>> I have customized the toolbar.  One of the icons I have set up as
>> the little paintbrush, and the command associated with it is
>> 'Insert Graphic'.  There is no key command normally associated with
>> this command.  It is also far down the menu so that I have to scroll
>> to get to it.  In this situation, the icon is easy to identify and is
>> much faster than trying to get to the menu.
>
> But there's nothing stopping you from assigning a key command to 'Insert
> Graphic', since Word allows you to assign key commands to any command.

  Yes, but conceivably one could have so many keyboard commands in word
that it is easy to forget what one might be.  However, a familiar icon
in the toolbar is hard to forget.

Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!
>From [e-mail] (eric larson)
Subject: Where have the standards gone? [a high level question]
Date: 20 Aug 94 09:31:50 -
Organization: FidoNet: Shockwave Rider, USR V.Everything [phone]

 > That said, let me add that it *is* important for UIs to develop; I'm not
 > going to advocate cast-in-platinum Human Interface Guidelines. The
 > _Macintosh Humand Interface Guidelines_ discuss the subject of ``Going
 > Beyond the Guidelines'' quite specifically.

 > So, in short: yes, this bothers me. Who else?

Me too. The consistency of the Apple user interface has long been one of it's
strengths. Having so many disparate design elements onscreen is quite jarring
to someone really used to the standard ways of doing things.

It's one thing to introduce new elements to support new technologies (OpenDoc's
interface elements might well need to EXTEND the current paradigm
considerably), or to replace elements when a better way becomes obvious. But it
should be done in a CONSISTENT fashion. The Zoom box should be the same on
EVERYTHING. The StickyNotes stuff is an abomination.

+++++++++++++++++++++++++++

>From [e-mail] (Klaus)
Date: 29 Aug 1994 02:13:11 GMT
Organization: Parentheses and Ellipses

In article <[e-mail]>
Jens Alfke <[e-mail]> writes:

> The fundamental issue is that the HI has to move forward;
> that the old mostly black and white interface is getting old.

What does it mean for the HI to "move forward"?  Yes, the interface is getting
old, but that doesn't mean it's going bad.  As someone once remarked, the
usual windows interface looks like an explosion in a cartoon factory.  A wild
jumble of colors and patterns, for no apparent reason other than to look
whizzy.  It's the computer equivalent of those stereo components with lots of
pointless buttons and flashing lights whose only purpose is to make the box
look high-tech.  In fact, it just looks tacky.  I think one of the reasons
that graphic design professionals like to use Macs is that the Mac has an
elegant interface.  I'd hate to see Apple give up that elegance in the name of
"moving forward."

>> - the Find File windows have a funky styled background
> So do the majority of new commercial products these days, or at least a
> gray background. There's no law saying all windows have to be white.

No, there's no law, but it violates one of the principles of user interface
design: consistency.  One should not change the interface unless there is a
good reason for the change

 -Klaus ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Klaus)
Date: 29 Aug 1994 02:23:43 GMT
Organization: Parentheses and Ellipses

In article <[e-mail]>
[e-mail] (Mike Balfour) writes:

> Well, here's a little something to consider before jumping on Apple.  It
> could be that they're ditching some of these standards because the user
> wants it that way

What I suspect is that it's not the current Mac users who want it that way,
but the Windows users whom Apple is trying to win over.  Unfortunately, making
a Mac look like a Windows box isn't likely to win over many Windows users, but
it'll probably alienate a lot of Mac users.  Most Windows users have chosen
their platform because it's the most common one, or because there are more
applications (especially games) available for it.  Most Mac users have chosen
their platform because of its elegant and consistent interface.  Making the
Mac more like a Windows box won't really give  the Windows users any reasons
to switch, but it may well make some Mac users decide that there's no reason
to stick with the Mac.

 -Klaus ([e-mail])

---------------------------

End of C.S.M.P. Digest
**********************


ˇ